From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0002.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0001.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0003.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0002.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0002.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0002.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0001.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment.pl From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0004.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0003.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0003.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0003.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0002.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0001.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0005.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0004.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0004.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0004.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0003.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0003.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0006.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0005.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0005.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0005.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0004.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0004.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0007.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0006.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0006.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0006.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0005.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0005.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0002.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0001.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0001.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment.html From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0008.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0007.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0007.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0007.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0006.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0006.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0003.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0002.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0002.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0003.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0001.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0001.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0001.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0009.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0008.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0008.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0008.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0007.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0007.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0004.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0003.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0003.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0007.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0003.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0002.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0002.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0002.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0002.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0002.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0002.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0001.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0010.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0009.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0009.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0009.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0008.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0008.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0005.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0004.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0004.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0008.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0009.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0004.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0003.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0003.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0003.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0003.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0003.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0003.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0002.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0002.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0002.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0002.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0011.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0010.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0010.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0010.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0009.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0009.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0006.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0005.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0005.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0010.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0011.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0005.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0004.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0004.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0004.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0004.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0004.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0004.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0003.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0003.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0003.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0003.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0012.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0011.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0011.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0011.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0010.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0010.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0007.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0006.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0006.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0006.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0012.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0013.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0006.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0005.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0005.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0005.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0005.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0005.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0005.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0004.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0004.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0004.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0004.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0013.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0012.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0012.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0012.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0011.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0011.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0008.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0007.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0007.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0007.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0014.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0015.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0007.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0006.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0006.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0006.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0006.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0006.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0006.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0006.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0005.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0005.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0005.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0005.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0014.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0013.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0013.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0013.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0012.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0012.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0009.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0008.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0008.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0008.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0016.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0017.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0008.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0007.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0007.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0007.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0007.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0007.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0007.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0007.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0006.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0006.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0006.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0006.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0006.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0006.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0002.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0015.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0014.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0014.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0014.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0013.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0013.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0010.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0009.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0009.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0009.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0018.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0019.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0009.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0008.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0008.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0008.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0008.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0008.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0008.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0008.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0007.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0007.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0007.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0007.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0007.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0007.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0003.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0016.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0015.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0015.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0015.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0014.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0014.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0011.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0010.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0010.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0010.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0020.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0021.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0010.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0009.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0009.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0009.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0009.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0009.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0009.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0009.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0008.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0008.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0008.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0008.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0008.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0008.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0004.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0001.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0017.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0016.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0016.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0016.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0015.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0015.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0012.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0011.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0011.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0011.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0022.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0023.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0011.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0010.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0010.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0010.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0010.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0010.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0010.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0010.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0009.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0009.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0009.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0009.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0009.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0009.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0005.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0002.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0002.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0002.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0018.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0017.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0017.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0017.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0016.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0016.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0013.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0012.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0012.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0012.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0024.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0025.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0012.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0011.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0011.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0011.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0011.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0011.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0011.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0011.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0010.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0010.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0010.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0010.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0010.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0010.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0006.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0003.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0003.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0003.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0001.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0001.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0019.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0018.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0018.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0018.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0017.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0017.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0014.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0013.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0013.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0013.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0026.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0027.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0013.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0012.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0012.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0012.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0012.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0012.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0012.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0012.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0011.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0011.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0011.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0011.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0011.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0011.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0007.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0004.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0004.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0004.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0003.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0003.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0020.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0019.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0019.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0019.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0018.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0018.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0015.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0014.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0014.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0014.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0028.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0029.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0014.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0013.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0013.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0013.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0013.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0013.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0013.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0013.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0012.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0012.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0012.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0012.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0012.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0012.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0008.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0005.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0005.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0005.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0004.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0004.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0021.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0020.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0020.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0020.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0019.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0019.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0016.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0015.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0015.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0015.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0030.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0031.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0015.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0014.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0014.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0014.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0014.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0014.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0014.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0014.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0013.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0013.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0013.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0013.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0013.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0013.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0009.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0006.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0006.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0006.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0005.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0005.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment-0001.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From ajmas at sympatico.ca Tue Jan 22 07:16:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 09:16:10 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On 20-Jan-08, at 07:53 , Dr. Douglas Lyon wrote: > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? I was thinking about this, and while Maven and Ant are great tools, they only solve the Java side of things. The building of RXTX for the most part involves native code and this is where tools such as Make and Configure have their strengths. They may not necessarily be the greatest things since slide bread, but trying to deal with differences in architectures and assumptions of different platforms is quite an arduous ordeal. If there are better tools to dealing with the building of native code on different platforms, then I am not aware of them. It should be noted that I have once made a native build file with Ant, but it depended on non-standard tasks, meaning something else to install, and it wouldn't have dealt well with trying to work out the specifics on each individual platform. Andre From james.i.brannan at lmco.com Tue Jan 22 08:19:32 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 10:19:32 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Regarding the not reproducable...is it possible then the problem might lie with the RTS? Remember, what's happening is that the RTS is powering the CTS. It doesn't seem likely, though, as all the sensors are doing is opening/closing the flow between RTS and CTS. I will try this on another pc and see if I get the same behavior. From james.i.brannan at lmco.com Tue Jan 22 09:32:40 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 11:32:40 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Sorry about the code...I a little bit of unused code from it to make it shorter. Remember, I experienced the same results using RXTX without the dongle. Errr....oops, I just realized something though, we are *NOT* doing the same test. Seems I forgot to unattach the DSR sensor....so in fact the RXTX code is getting both CTS and DSR signals (I'm just not handling it in my listener)....sorry about that detail. I will have to test again tonight one with both sensors, one with only CTS. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, January 22, 2008 11:27 AM To: Brannan, James I (N-Fenestra) Cc: tjarvi at qbang.org Subject: RE: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm I really doubt it. Microsoft and Sun did _not_ get along back then. Remember the antitrust case. Microsoft would not share undocumented APIs. The serial API is fairly close to being 'on the hardware' as it is. There would not be much underneath. I have two and a half suspicions. The first is that for some reason the voltage was not enough to trigger cts consistantly. The second is you used a USB dongle with rxtx and it's kernel driver isn't doing what is expected. The half suspicion is your code did not compile. Are you sure we are trying the exact same test? I had to add the port enumeration to get CommPortIdentifier. The test of cts was unchanged. Perhaps you are doing something with a GUI and by chance, rxtx is being impacted. btw, I was just triggering from a live wire from the serial port too. The only difference is I used only a wire between the pins (in a breakout box). Why don't you mail me the dll you used just so I can verify that it wasnt something different in the native code. I doubt it but we can try. On Tue, 22 Jan 2008, Brannan, James I (N-Fenestra) wrote: > Dumb question...is it possible that Sun is accessing the underlying port > bypassing the layer RXTX uses? > > -----Original Message----- > From: Brannan, James I (N-Fenestra) > Sent: Tuesday, January 22, 2008 10:20 AM > To: 'rxtx at qbang.org' > Cc: 'tjarvi at qbang.org' > Subject: Re: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm > > Regarding the not reproducable...is it possible then the problem might > lie with the RTS? Remember, what's happening is that the RTS is > powering the CTS. It doesn't seem likely, though, as all the sensors > are doing is opening/closing the flow between RTS and CTS. I will try > this on another pc and see if I get the same behavior. > From Bob_Jacobsen at lbl.gov Tue Jan 22 09:54:22 2008 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 22 Jan 2008 08:54:22 -0800 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: At 10:19 AM -0500 1/22/08, Brannan, James I (N-Fenestra) wrote: >Regarding the not reproducable...is it possible then the problem might >lie with the RTS? Remember, what's happening is that the RTS is >powering the CTS. It doesn't seem likely, though, as all the sensors >are doing is opening/closing the flow between RTS and CTS. I will try >this on another pc and see if I get the same behavior. Make sure that you have all the flow control options explicitly disabled in your code, so that there's no "automagic" attempts to change the various control leads. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Tue Jan 22 10:25:33 2008 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 22 Jan 2008 09:25:33 -0800 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. Anyone on the list ever use autoconf and automake? > It should be noted that I have once made a native build file with Ant, > but it depended on non-standard tasks, meaning something else to > install, > and it wouldn't have dealt well with trying to work out the specifics > on each individual platform. Ant can bootstrap non-standard tasks (i.e. fetch and run) without requiring the user to install them. I'm not suggesting that Ant is an appropriate way to build the native code, just that there's ways to do it without forcing the user to install ant extensions manually. Here's a snippet for bootstrapping the maven-artifact-ant plugin in a build.xml file: ... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080122/fe76b6ba/attachment.html From ajmas at sympatico.ca Tue Jan 22 18:23:26 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 20:23:26 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. > > Anyone on the list ever use autoconf and automake? We already use autoconf. The configure script is the result of running autoconf, taking configure.in as input. Andre From jamesbrannan at earthlink.net Tue Jan 22 20:46:47 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Tue, 22 Jan 2008 22:46:47 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> I did notice in your printout some inconsistencies in the readings, albeit not nearly what I experienced. Were you able to keep the rate of events constant? I was able to keep them very constant this time when I tested. Duplicated the test today. This time I removed the cadence magnet so that DSR event was never raised (circuit was never closed for DSR). I also didnt use a dongle. Only CTS events would be raised this time. Same results, RXTX would not consistently raise CTS events on my Windows XP, the Sun Comm API would. Also, I redid the Linux test, same results,RXTX performed remarkably. So, I'm trying to think what the next step would be. I suppose I should try it using another PC, however, it seems to me that if it was my operating system/computer setup Sun's would have a problem too. I'm thinking/hoping as OS X is really BSD, that it should work on OS X, though I wont know until this weekend. What would you suggest as the next step I should take? Results follow, same code as before. The difference is striking. When I watch the RXTX on windows, its as if Windows just isnt registering events at all for a second, then suddenly deciding to register events for a second or so, not register events, register events...like something is blocking or hanging. My next step is to figure out how to build the windows dll, and add in some debugging code to it, unless you think that's not worthwhile at this point. RXTX Windows: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201055567796E12Speed: 6.273481595715637E-9 cts change: 9688.0Speed: 0.7777456647398844 cts change: 312.0Speed: 24.150000000000002 cts change: 2657.0Speed: 2.8358298833270608 cts change: 640.0Speed: 11.773125 cts change: 2110.0Speed: 3.570995260663507 cts change: 312.0Speed: 24.150000000000002 cts change: 3360.0Speed: 2.2425 cts change: 5546.0Speed: 1.3586007933645872 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 5860.0Speed: 1.28580204778157 cts change: 937.0Speed: 8.041408751334044 cts change: 625.0Speed: 12.05568 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 625.0Speed: 12.05568 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 938.0Speed: 8.032835820895523 cts change: 1250.0Speed: 6.02784 cts change: 17265.0Speed: 0.4364205039096438 cts change: 3125.0Speed: 2.411136 cts change: 2500.0Speed: 3.01392 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 625.0Speed: 12.05568 cts change: 7032.0Speed: 1.0715017064846417 cts change: 625.0Speed: 12.05568 cts change: 8593.0Speed: 0.8768532526475038 cts change: 2907.0Speed: 2.5919504643962847 cts change: 1953.0Speed: 3.8580645161290326 cts change: 2578.0Speed: 2.9227307990690456 cts change: 3203.0Speed: 2.352419606618795 cts change: 2891.0Speed: 2.6062953995157385 cts change: 312.0Speed: 24.150000000000002 cts change: 5078.0Speed: 1.4838125246159906 cts change: 3516.0Speed: 2.1430034129692834 cts change: 2891.0Speed: 2.6062953995157385 cts change: 3515.0Speed: 2.1436130867709817 cts change: 313.0Speed: 24.072843450479233 cts change: 2265.0Speed: 3.3266225165562915 cts change: 313.0Speed: 24.072843450479233 cts change: 2578.0Speed: 2.9227307990690456 Sun's Comm DLL Windows ============================================================= cts change: 1.201055798875E12Speed: 6.27348038871938E-9 cts change: 421.0Speed: 17.897387173396677 cts change: 344.0Speed: 21.903488372093022 cts change: 328.0Speed: 22.971951219512196 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 297.0Speed: 25.36969696969697 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 282.0Speed: 26.719148936170214 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 328.0Speed: 22.971951219512196 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 RXTX Linux: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201052778098E12Speed: 6.2734961671977396E-9 cts change: 408.0Speed: 18.46764705882353 cts change: 372.0Speed: 20.25483870967742 cts change: 332.0Speed: 22.695180722891568 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 296.0Speed: 25.455405405405408 cts change: 292.0Speed: 25.804109589041097 cts change: 304.0Speed: 24.785526315789475 cts change: 292.0Speed: 25.804109589041097 cts change: 300.0Speed: 25.116 cts change: 304.0Speed: 24.785526315789475 cts change: 304.0Speed: 24.785526315789475 cts change: 316.0Speed: 23.844303797468356 cts change: 296.0Speed: 25.455405405405408 cts change: 304.0Speed: 24.785526315789475 cts change: 308.0Speed: 24.463636363636365 cts change: 300.0Speed: 25.116 cts change: 316.0Speed: 23.844303797468356 cts change: 305.0Speed: 24.704262295081968 cts change: 307.0Speed: 24.543322475570033 cts change: 312.0Speed: 24.150000000000002 cts change: 300.0Speed: 25.116 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 315.0Speed: 23.92 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 313.0Speed: 24.072843450479233 cts change: 319.0Speed: 23.620062695924766 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 324.0Speed: 23.255555555555556 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 328.0Speed: 22.971951219512196 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 328.0Speed: 22.971951219512196 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 313.0Speed: 24.072843450479233 cts change: 303.0Speed: 24.867326732673266 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 311.0Speed: 24.227652733118973 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 304.0Speed: 24.785526315789475 From tjarvi at qbang.org Tue Jan 22 21:01:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Jan 2008 21:01:25 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Message-ID: On Tue, 22 Jan 2008, James Brannan wrote: > I did notice in your printout some inconsistencies in the readings, albeit > not nearly what I experienced. Were you able to keep the rate of events > constant? I was not able to keep a constant rate as the timing showed. But as I watched the printout, nothing unexpected was observed. I'll need to build a opamp circuit on a breadboard to be more consistant. I've asked a few questions that I'll repeat now. 1) Is there more code than you posted in your tests? The code you posted does not even compile. 2) Are you using an onboard UART or a USB dongle? 3) could you provide a link to the exact rxtx library you are using? What I see is sane behavior that does not agree with your observations which amount to ~5 or more missed events. I certainly would see that while playing 'morse code' on a breakout box. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0022.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0021.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0021.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0021.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0020.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0020.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0017.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0016.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0016.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0016.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0032.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0033.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0016.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0015.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0015.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0015.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0015.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0015.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0015.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0015.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0014.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0014.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0014.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0014.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0014.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0014.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0010.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0007.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0007.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0007.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0006.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0006.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment-0003.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From ajmas at sympatico.ca Tue Jan 22 07:16:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 09:16:10 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On 20-Jan-08, at 07:53 , Dr. Douglas Lyon wrote: > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? I was thinking about this, and while Maven and Ant are great tools, they only solve the Java side of things. The building of RXTX for the most part involves native code and this is where tools such as Make and Configure have their strengths. They may not necessarily be the greatest things since slide bread, but trying to deal with differences in architectures and assumptions of different platforms is quite an arduous ordeal. If there are better tools to dealing with the building of native code on different platforms, then I am not aware of them. It should be noted that I have once made a native build file with Ant, but it depended on non-standard tasks, meaning something else to install, and it wouldn't have dealt well with trying to work out the specifics on each individual platform. Andre From james.i.brannan at lmco.com Tue Jan 22 08:19:32 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 10:19:32 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Regarding the not reproducable...is it possible then the problem might lie with the RTS? Remember, what's happening is that the RTS is powering the CTS. It doesn't seem likely, though, as all the sensors are doing is opening/closing the flow between RTS and CTS. I will try this on another pc and see if I get the same behavior. From james.i.brannan at lmco.com Tue Jan 22 09:32:40 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 11:32:40 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Sorry about the code...I a little bit of unused code from it to make it shorter. Remember, I experienced the same results using RXTX without the dongle. Errr....oops, I just realized something though, we are *NOT* doing the same test. Seems I forgot to unattach the DSR sensor....so in fact the RXTX code is getting both CTS and DSR signals (I'm just not handling it in my listener)....sorry about that detail. I will have to test again tonight one with both sensors, one with only CTS. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, January 22, 2008 11:27 AM To: Brannan, James I (N-Fenestra) Cc: tjarvi at qbang.org Subject: RE: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm I really doubt it. Microsoft and Sun did _not_ get along back then. Remember the antitrust case. Microsoft would not share undocumented APIs. The serial API is fairly close to being 'on the hardware' as it is. There would not be much underneath. I have two and a half suspicions. The first is that for some reason the voltage was not enough to trigger cts consistantly. The second is you used a USB dongle with rxtx and it's kernel driver isn't doing what is expected. The half suspicion is your code did not compile. Are you sure we are trying the exact same test? I had to add the port enumeration to get CommPortIdentifier. The test of cts was unchanged. Perhaps you are doing something with a GUI and by chance, rxtx is being impacted. btw, I was just triggering from a live wire from the serial port too. The only difference is I used only a wire between the pins (in a breakout box). Why don't you mail me the dll you used just so I can verify that it wasnt something different in the native code. I doubt it but we can try. On Tue, 22 Jan 2008, Brannan, James I (N-Fenestra) wrote: > Dumb question...is it possible that Sun is accessing the underlying port > bypassing the layer RXTX uses? > > -----Original Message----- > From: Brannan, James I (N-Fenestra) > Sent: Tuesday, January 22, 2008 10:20 AM > To: 'rxtx at qbang.org' > Cc: 'tjarvi at qbang.org' > Subject: Re: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm > > Regarding the not reproducable...is it possible then the problem might > lie with the RTS? Remember, what's happening is that the RTS is > powering the CTS. It doesn't seem likely, though, as all the sensors > are doing is opening/closing the flow between RTS and CTS. I will try > this on another pc and see if I get the same behavior. > From Bob_Jacobsen at lbl.gov Tue Jan 22 09:54:22 2008 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 22 Jan 2008 08:54:22 -0800 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: At 10:19 AM -0500 1/22/08, Brannan, James I (N-Fenestra) wrote: >Regarding the not reproducable...is it possible then the problem might >lie with the RTS? Remember, what's happening is that the RTS is >powering the CTS. It doesn't seem likely, though, as all the sensors >are doing is opening/closing the flow between RTS and CTS. I will try >this on another pc and see if I get the same behavior. Make sure that you have all the flow control options explicitly disabled in your code, so that there's no "automagic" attempts to change the various control leads. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Tue Jan 22 10:25:33 2008 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 22 Jan 2008 09:25:33 -0800 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. Anyone on the list ever use autoconf and automake? > It should be noted that I have once made a native build file with Ant, > but it depended on non-standard tasks, meaning something else to > install, > and it wouldn't have dealt well with trying to work out the specifics > on each individual platform. Ant can bootstrap non-standard tasks (i.e. fetch and run) without requiring the user to install them. I'm not suggesting that Ant is an appropriate way to build the native code, just that there's ways to do it without forcing the user to install ant extensions manually. Here's a snippet for bootstrapping the maven-artifact-ant plugin in a build.xml file: ... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080122/fe76b6ba/attachment-0002.html From ajmas at sympatico.ca Tue Jan 22 18:23:26 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 20:23:26 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. > > Anyone on the list ever use autoconf and automake? We already use autoconf. The configure script is the result of running autoconf, taking configure.in as input. Andre From jamesbrannan at earthlink.net Tue Jan 22 20:46:47 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Tue, 22 Jan 2008 22:46:47 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> I did notice in your printout some inconsistencies in the readings, albeit not nearly what I experienced. Were you able to keep the rate of events constant? I was able to keep them very constant this time when I tested. Duplicated the test today. This time I removed the cadence magnet so that DSR event was never raised (circuit was never closed for DSR). I also didnt use a dongle. Only CTS events would be raised this time. Same results, RXTX would not consistently raise CTS events on my Windows XP, the Sun Comm API would. Also, I redid the Linux test, same results,RXTX performed remarkably. So, I'm trying to think what the next step would be. I suppose I should try it using another PC, however, it seems to me that if it was my operating system/computer setup Sun's would have a problem too. I'm thinking/hoping as OS X is really BSD, that it should work on OS X, though I wont know until this weekend. What would you suggest as the next step I should take? Results follow, same code as before. The difference is striking. When I watch the RXTX on windows, its as if Windows just isnt registering events at all for a second, then suddenly deciding to register events for a second or so, not register events, register events...like something is blocking or hanging. My next step is to figure out how to build the windows dll, and add in some debugging code to it, unless you think that's not worthwhile at this point. RXTX Windows: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201055567796E12Speed: 6.273481595715637E-9 cts change: 9688.0Speed: 0.7777456647398844 cts change: 312.0Speed: 24.150000000000002 cts change: 2657.0Speed: 2.8358298833270608 cts change: 640.0Speed: 11.773125 cts change: 2110.0Speed: 3.570995260663507 cts change: 312.0Speed: 24.150000000000002 cts change: 3360.0Speed: 2.2425 cts change: 5546.0Speed: 1.3586007933645872 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 5860.0Speed: 1.28580204778157 cts change: 937.0Speed: 8.041408751334044 cts change: 625.0Speed: 12.05568 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 625.0Speed: 12.05568 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 938.0Speed: 8.032835820895523 cts change: 1250.0Speed: 6.02784 cts change: 17265.0Speed: 0.4364205039096438 cts change: 3125.0Speed: 2.411136 cts change: 2500.0Speed: 3.01392 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 625.0Speed: 12.05568 cts change: 7032.0Speed: 1.0715017064846417 cts change: 625.0Speed: 12.05568 cts change: 8593.0Speed: 0.8768532526475038 cts change: 2907.0Speed: 2.5919504643962847 cts change: 1953.0Speed: 3.8580645161290326 cts change: 2578.0Speed: 2.9227307990690456 cts change: 3203.0Speed: 2.352419606618795 cts change: 2891.0Speed: 2.6062953995157385 cts change: 312.0Speed: 24.150000000000002 cts change: 5078.0Speed: 1.4838125246159906 cts change: 3516.0Speed: 2.1430034129692834 cts change: 2891.0Speed: 2.6062953995157385 cts change: 3515.0Speed: 2.1436130867709817 cts change: 313.0Speed: 24.072843450479233 cts change: 2265.0Speed: 3.3266225165562915 cts change: 313.0Speed: 24.072843450479233 cts change: 2578.0Speed: 2.9227307990690456 Sun's Comm DLL Windows ============================================================= cts change: 1.201055798875E12Speed: 6.27348038871938E-9 cts change: 421.0Speed: 17.897387173396677 cts change: 344.0Speed: 21.903488372093022 cts change: 328.0Speed: 22.971951219512196 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 297.0Speed: 25.36969696969697 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 282.0Speed: 26.719148936170214 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 328.0Speed: 22.971951219512196 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 RXTX Linux: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201052778098E12Speed: 6.2734961671977396E-9 cts change: 408.0Speed: 18.46764705882353 cts change: 372.0Speed: 20.25483870967742 cts change: 332.0Speed: 22.695180722891568 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 296.0Speed: 25.455405405405408 cts change: 292.0Speed: 25.804109589041097 cts change: 304.0Speed: 24.785526315789475 cts change: 292.0Speed: 25.804109589041097 cts change: 300.0Speed: 25.116 cts change: 304.0Speed: 24.785526315789475 cts change: 304.0Speed: 24.785526315789475 cts change: 316.0Speed: 23.844303797468356 cts change: 296.0Speed: 25.455405405405408 cts change: 304.0Speed: 24.785526315789475 cts change: 308.0Speed: 24.463636363636365 cts change: 300.0Speed: 25.116 cts change: 316.0Speed: 23.844303797468356 cts change: 305.0Speed: 24.704262295081968 cts change: 307.0Speed: 24.543322475570033 cts change: 312.0Speed: 24.150000000000002 cts change: 300.0Speed: 25.116 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 315.0Speed: 23.92 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 313.0Speed: 24.072843450479233 cts change: 319.0Speed: 23.620062695924766 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 324.0Speed: 23.255555555555556 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 328.0Speed: 22.971951219512196 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 328.0Speed: 22.971951219512196 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 313.0Speed: 24.072843450479233 cts change: 303.0Speed: 24.867326732673266 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 311.0Speed: 24.227652733118973 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 304.0Speed: 24.785526315789475 From tjarvi at qbang.org Tue Jan 22 21:01:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Jan 2008 21:01:25 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Message-ID: On Tue, 22 Jan 2008, James Brannan wrote: > I did notice in your printout some inconsistencies in the readings, albeit > not nearly what I experienced. Were you able to keep the rate of events > constant? I was not able to keep a constant rate as the timing showed. But as I watched the printout, nothing unexpected was observed. I'll need to build a opamp circuit on a breadboard to be more consistant. I've asked a few questions that I'll repeat now. 1) Is there more code than you posted in your tests? The code you posted does not even compile. 2) Are you using an onboard UART or a USB dongle? 3) could you provide a link to the exact rxtx library you are using? What I see is sane behavior that does not agree with your observations which amount to ~5 or more missed events. I certainly would see that while playing 'morse code' on a breakout box. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0023.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0022.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0022.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0022.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0021.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0021.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0018.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0017.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0017.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0017.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0034.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0035.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0017.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0016.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0016.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0016.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0016.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0016.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0016.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0016.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0015.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0015.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0015.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0015.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0015.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0015.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0011.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0008.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0008.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0008.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0007.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0007.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment-0004.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From ajmas at sympatico.ca Tue Jan 22 07:16:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 09:16:10 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On 20-Jan-08, at 07:53 , Dr. Douglas Lyon wrote: > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? I was thinking about this, and while Maven and Ant are great tools, they only solve the Java side of things. The building of RXTX for the most part involves native code and this is where tools such as Make and Configure have their strengths. They may not necessarily be the greatest things since slide bread, but trying to deal with differences in architectures and assumptions of different platforms is quite an arduous ordeal. If there are better tools to dealing with the building of native code on different platforms, then I am not aware of them. It should be noted that I have once made a native build file with Ant, but it depended on non-standard tasks, meaning something else to install, and it wouldn't have dealt well with trying to work out the specifics on each individual platform. Andre From james.i.brannan at lmco.com Tue Jan 22 08:19:32 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 10:19:32 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Regarding the not reproducable...is it possible then the problem might lie with the RTS? Remember, what's happening is that the RTS is powering the CTS. It doesn't seem likely, though, as all the sensors are doing is opening/closing the flow between RTS and CTS. I will try this on another pc and see if I get the same behavior. From james.i.brannan at lmco.com Tue Jan 22 09:32:40 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 11:32:40 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Sorry about the code...I a little bit of unused code from it to make it shorter. Remember, I experienced the same results using RXTX without the dongle. Errr....oops, I just realized something though, we are *NOT* doing the same test. Seems I forgot to unattach the DSR sensor....so in fact the RXTX code is getting both CTS and DSR signals (I'm just not handling it in my listener)....sorry about that detail. I will have to test again tonight one with both sensors, one with only CTS. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, January 22, 2008 11:27 AM To: Brannan, James I (N-Fenestra) Cc: tjarvi at qbang.org Subject: RE: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm I really doubt it. Microsoft and Sun did _not_ get along back then. Remember the antitrust case. Microsoft would not share undocumented APIs. The serial API is fairly close to being 'on the hardware' as it is. There would not be much underneath. I have two and a half suspicions. The first is that for some reason the voltage was not enough to trigger cts consistantly. The second is you used a USB dongle with rxtx and it's kernel driver isn't doing what is expected. The half suspicion is your code did not compile. Are you sure we are trying the exact same test? I had to add the port enumeration to get CommPortIdentifier. The test of cts was unchanged. Perhaps you are doing something with a GUI and by chance, rxtx is being impacted. btw, I was just triggering from a live wire from the serial port too. The only difference is I used only a wire between the pins (in a breakout box). Why don't you mail me the dll you used just so I can verify that it wasnt something different in the native code. I doubt it but we can try. On Tue, 22 Jan 2008, Brannan, James I (N-Fenestra) wrote: > Dumb question...is it possible that Sun is accessing the underlying port > bypassing the layer RXTX uses? > > -----Original Message----- > From: Brannan, James I (N-Fenestra) > Sent: Tuesday, January 22, 2008 10:20 AM > To: 'rxtx at qbang.org' > Cc: 'tjarvi at qbang.org' > Subject: Re: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm > > Regarding the not reproducable...is it possible then the problem might > lie with the RTS? Remember, what's happening is that the RTS is > powering the CTS. It doesn't seem likely, though, as all the sensors > are doing is opening/closing the flow between RTS and CTS. I will try > this on another pc and see if I get the same behavior. > From Bob_Jacobsen at lbl.gov Tue Jan 22 09:54:22 2008 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 22 Jan 2008 08:54:22 -0800 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: At 10:19 AM -0500 1/22/08, Brannan, James I (N-Fenestra) wrote: >Regarding the not reproducable...is it possible then the problem might >lie with the RTS? Remember, what's happening is that the RTS is >powering the CTS. It doesn't seem likely, though, as all the sensors >are doing is opening/closing the flow between RTS and CTS. I will try >this on another pc and see if I get the same behavior. Make sure that you have all the flow control options explicitly disabled in your code, so that there's no "automagic" attempts to change the various control leads. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Tue Jan 22 10:25:33 2008 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 22 Jan 2008 09:25:33 -0800 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. Anyone on the list ever use autoconf and automake? > It should be noted that I have once made a native build file with Ant, > but it depended on non-standard tasks, meaning something else to > install, > and it wouldn't have dealt well with trying to work out the specifics > on each individual platform. Ant can bootstrap non-standard tasks (i.e. fetch and run) without requiring the user to install them. I'm not suggesting that Ant is an appropriate way to build the native code, just that there's ways to do it without forcing the user to install ant extensions manually. Here's a snippet for bootstrapping the maven-artifact-ant plugin in a build.xml file: ... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080122/fe76b6ba/attachment-0003.html From ajmas at sympatico.ca Tue Jan 22 18:23:26 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 20:23:26 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. > > Anyone on the list ever use autoconf and automake? We already use autoconf. The configure script is the result of running autoconf, taking configure.in as input. Andre From jamesbrannan at earthlink.net Tue Jan 22 20:46:47 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Tue, 22 Jan 2008 22:46:47 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> I did notice in your printout some inconsistencies in the readings, albeit not nearly what I experienced. Were you able to keep the rate of events constant? I was able to keep them very constant this time when I tested. Duplicated the test today. This time I removed the cadence magnet so that DSR event was never raised (circuit was never closed for DSR). I also didnt use a dongle. Only CTS events would be raised this time. Same results, RXTX would not consistently raise CTS events on my Windows XP, the Sun Comm API would. Also, I redid the Linux test, same results,RXTX performed remarkably. So, I'm trying to think what the next step would be. I suppose I should try it using another PC, however, it seems to me that if it was my operating system/computer setup Sun's would have a problem too. I'm thinking/hoping as OS X is really BSD, that it should work on OS X, though I wont know until this weekend. What would you suggest as the next step I should take? Results follow, same code as before. The difference is striking. When I watch the RXTX on windows, its as if Windows just isnt registering events at all for a second, then suddenly deciding to register events for a second or so, not register events, register events...like something is blocking or hanging. My next step is to figure out how to build the windows dll, and add in some debugging code to it, unless you think that's not worthwhile at this point. RXTX Windows: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201055567796E12Speed: 6.273481595715637E-9 cts change: 9688.0Speed: 0.7777456647398844 cts change: 312.0Speed: 24.150000000000002 cts change: 2657.0Speed: 2.8358298833270608 cts change: 640.0Speed: 11.773125 cts change: 2110.0Speed: 3.570995260663507 cts change: 312.0Speed: 24.150000000000002 cts change: 3360.0Speed: 2.2425 cts change: 5546.0Speed: 1.3586007933645872 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 5860.0Speed: 1.28580204778157 cts change: 937.0Speed: 8.041408751334044 cts change: 625.0Speed: 12.05568 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 625.0Speed: 12.05568 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 938.0Speed: 8.032835820895523 cts change: 1250.0Speed: 6.02784 cts change: 17265.0Speed: 0.4364205039096438 cts change: 3125.0Speed: 2.411136 cts change: 2500.0Speed: 3.01392 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 625.0Speed: 12.05568 cts change: 7032.0Speed: 1.0715017064846417 cts change: 625.0Speed: 12.05568 cts change: 8593.0Speed: 0.8768532526475038 cts change: 2907.0Speed: 2.5919504643962847 cts change: 1953.0Speed: 3.8580645161290326 cts change: 2578.0Speed: 2.9227307990690456 cts change: 3203.0Speed: 2.352419606618795 cts change: 2891.0Speed: 2.6062953995157385 cts change: 312.0Speed: 24.150000000000002 cts change: 5078.0Speed: 1.4838125246159906 cts change: 3516.0Speed: 2.1430034129692834 cts change: 2891.0Speed: 2.6062953995157385 cts change: 3515.0Speed: 2.1436130867709817 cts change: 313.0Speed: 24.072843450479233 cts change: 2265.0Speed: 3.3266225165562915 cts change: 313.0Speed: 24.072843450479233 cts change: 2578.0Speed: 2.9227307990690456 Sun's Comm DLL Windows ============================================================= cts change: 1.201055798875E12Speed: 6.27348038871938E-9 cts change: 421.0Speed: 17.897387173396677 cts change: 344.0Speed: 21.903488372093022 cts change: 328.0Speed: 22.971951219512196 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 297.0Speed: 25.36969696969697 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 282.0Speed: 26.719148936170214 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 328.0Speed: 22.971951219512196 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 RXTX Linux: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201052778098E12Speed: 6.2734961671977396E-9 cts change: 408.0Speed: 18.46764705882353 cts change: 372.0Speed: 20.25483870967742 cts change: 332.0Speed: 22.695180722891568 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 296.0Speed: 25.455405405405408 cts change: 292.0Speed: 25.804109589041097 cts change: 304.0Speed: 24.785526315789475 cts change: 292.0Speed: 25.804109589041097 cts change: 300.0Speed: 25.116 cts change: 304.0Speed: 24.785526315789475 cts change: 304.0Speed: 24.785526315789475 cts change: 316.0Speed: 23.844303797468356 cts change: 296.0Speed: 25.455405405405408 cts change: 304.0Speed: 24.785526315789475 cts change: 308.0Speed: 24.463636363636365 cts change: 300.0Speed: 25.116 cts change: 316.0Speed: 23.844303797468356 cts change: 305.0Speed: 24.704262295081968 cts change: 307.0Speed: 24.543322475570033 cts change: 312.0Speed: 24.150000000000002 cts change: 300.0Speed: 25.116 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 315.0Speed: 23.92 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 313.0Speed: 24.072843450479233 cts change: 319.0Speed: 23.620062695924766 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 324.0Speed: 23.255555555555556 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 328.0Speed: 22.971951219512196 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 328.0Speed: 22.971951219512196 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 313.0Speed: 24.072843450479233 cts change: 303.0Speed: 24.867326732673266 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 311.0Speed: 24.227652733118973 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 304.0Speed: 24.785526315789475 From tjarvi at qbang.org Tue Jan 22 21:01:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Jan 2008 21:01:25 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Message-ID: On Tue, 22 Jan 2008, James Brannan wrote: > I did notice in your printout some inconsistencies in the readings, albeit > not nearly what I experienced. Were you able to keep the rate of events > constant? I was not able to keep a constant rate as the timing showed. But as I watched the printout, nothing unexpected was observed. I'll need to build a opamp circuit on a breadboard to be more consistant. I've asked a few questions that I'll repeat now. 1) Is there more code than you posted in your tests? The code you posted does not even compile. 2) Are you using an onboard UART or a USB dongle? 3) could you provide a link to the exact rxtx library you are using? What I see is sane behavior that does not agree with your observations which amount to ~5 or more missed events. I certainly would see that while playing 'morse code' on a breakout box. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Thu Jan 24 11:35:02 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 24 Jan 2008 11:35:02 -0700 Subject: [Rxtx] macos compilation In-Reply-To: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> References: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> Message-ID: <2251ead40801241035k13765fedk8f523695be2b1122@mail.gmail.com> On 1/22/08, Andre-John Mas wrote: > > On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > > > > > Configuration appears to be where we are spending most of our time, > > > in the maintenance cycle. There has got to be a better way. Maven? > > > Ant? Suggestions? > > > > If there are better tools to dealing with the building of native code > > on different platforms, then I am not aware of them. > > > > Anyone on the list ever use autoconf and automake? > > We already use autoconf. The configure script is the result of running > autoconf, taking configure.in as input. I've been following the fight for "better autoconf/automake" since about 1997 - it starts to remind an old joke of IT managers of the day (1960s to 1990s) "choosing ${other-os} over Unix" with the punchline being "what part of the message you don't understand?" > Andre --vt From slacorte at ozengineering.com Thu Jan 24 18:05:22 2008 From: slacorte at ozengineering.com (Steven La Corte) Date: Thu, 24 Jan 2008 17:05:22 -0800 (PST) Subject: [Rxtx] rxtx solaris 2.9 SIGSEGV Message-ID: <448113.19444.qm@web412.biz.mail.mud.yahoo.com> We are using rxtx 2.1.7 in a Tomcat 5.5.7 servlet, that is running in Solaris 9 (SunOS 2.9). Our servlet opens 10 threads, and when a request is received, it opens a port, a readThr and writes and receives data from/to a serial port on a digi port server. The readThr is closed when processing is completed, and the port is closed. The servlet receives a request from a client every minute. The client is a cron tab application. The native code for the solaris was downloaded from the rxtx site and labelled for 32bit solaris 2.8. No changes or patches have been applied to the downloaded files (jar or .so). The servlet starts up, opens ports and successfully reads, writes and closes the port to the digi port server (and field devices connected to the digig port server) for a period of time (about one hour). Then we will notice that read attempts begin to not complete and appear to throw interrupt exceptions. Closing and reopening the port doesn't help, no data is still received. And finally, after some time, Tomcat will crash due to a SIGSEGV. I am attaching two typical HotSpot dumps. Any info that can be shared with us will be greatly appreciated. Thanks, Steve La Corte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1559.log Type: application/octet-stream Size: 8899 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid9786.log Type: application/octet-stream Size: 9310 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0003.obj From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0024.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0023.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0023.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0023.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0022.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0022.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0019.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0018.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0018.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0018.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0036.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0037.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0018.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0017.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0017.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0017.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0017.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0017.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0017.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0017.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0016.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0016.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0016.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0016.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0016.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0016.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0012.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0009.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0009.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0009.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0008.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0008.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment-0005.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From ajmas at sympatico.ca Tue Jan 22 07:16:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 09:16:10 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On 20-Jan-08, at 07:53 , Dr. Douglas Lyon wrote: > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? I was thinking about this, and while Maven and Ant are great tools, they only solve the Java side of things. The building of RXTX for the most part involves native code and this is where tools such as Make and Configure have their strengths. They may not necessarily be the greatest things since slide bread, but trying to deal with differences in architectures and assumptions of different platforms is quite an arduous ordeal. If there are better tools to dealing with the building of native code on different platforms, then I am not aware of them. It should be noted that I have once made a native build file with Ant, but it depended on non-standard tasks, meaning something else to install, and it wouldn't have dealt well with trying to work out the specifics on each individual platform. Andre From james.i.brannan at lmco.com Tue Jan 22 08:19:32 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 10:19:32 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Regarding the not reproducable...is it possible then the problem might lie with the RTS? Remember, what's happening is that the RTS is powering the CTS. It doesn't seem likely, though, as all the sensors are doing is opening/closing the flow between RTS and CTS. I will try this on another pc and see if I get the same behavior. From james.i.brannan at lmco.com Tue Jan 22 09:32:40 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 11:32:40 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Sorry about the code...I a little bit of unused code from it to make it shorter. Remember, I experienced the same results using RXTX without the dongle. Errr....oops, I just realized something though, we are *NOT* doing the same test. Seems I forgot to unattach the DSR sensor....so in fact the RXTX code is getting both CTS and DSR signals (I'm just not handling it in my listener)....sorry about that detail. I will have to test again tonight one with both sensors, one with only CTS. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, January 22, 2008 11:27 AM To: Brannan, James I (N-Fenestra) Cc: tjarvi at qbang.org Subject: RE: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm I really doubt it. Microsoft and Sun did _not_ get along back then. Remember the antitrust case. Microsoft would not share undocumented APIs. The serial API is fairly close to being 'on the hardware' as it is. There would not be much underneath. I have two and a half suspicions. The first is that for some reason the voltage was not enough to trigger cts consistantly. The second is you used a USB dongle with rxtx and it's kernel driver isn't doing what is expected. The half suspicion is your code did not compile. Are you sure we are trying the exact same test? I had to add the port enumeration to get CommPortIdentifier. The test of cts was unchanged. Perhaps you are doing something with a GUI and by chance, rxtx is being impacted. btw, I was just triggering from a live wire from the serial port too. The only difference is I used only a wire between the pins (in a breakout box). Why don't you mail me the dll you used just so I can verify that it wasnt something different in the native code. I doubt it but we can try. On Tue, 22 Jan 2008, Brannan, James I (N-Fenestra) wrote: > Dumb question...is it possible that Sun is accessing the underlying port > bypassing the layer RXTX uses? > > -----Original Message----- > From: Brannan, James I (N-Fenestra) > Sent: Tuesday, January 22, 2008 10:20 AM > To: 'rxtx at qbang.org' > Cc: 'tjarvi at qbang.org' > Subject: Re: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm > > Regarding the not reproducable...is it possible then the problem might > lie with the RTS? Remember, what's happening is that the RTS is > powering the CTS. It doesn't seem likely, though, as all the sensors > are doing is opening/closing the flow between RTS and CTS. I will try > this on another pc and see if I get the same behavior. > From Bob_Jacobsen at lbl.gov Tue Jan 22 09:54:22 2008 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 22 Jan 2008 08:54:22 -0800 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: At 10:19 AM -0500 1/22/08, Brannan, James I (N-Fenestra) wrote: >Regarding the not reproducable...is it possible then the problem might >lie with the RTS? Remember, what's happening is that the RTS is >powering the CTS. It doesn't seem likely, though, as all the sensors >are doing is opening/closing the flow between RTS and CTS. I will try >this on another pc and see if I get the same behavior. Make sure that you have all the flow control options explicitly disabled in your code, so that there's no "automagic" attempts to change the various control leads. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Tue Jan 22 10:25:33 2008 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 22 Jan 2008 09:25:33 -0800 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. Anyone on the list ever use autoconf and automake? > It should be noted that I have once made a native build file with Ant, > but it depended on non-standard tasks, meaning something else to > install, > and it wouldn't have dealt well with trying to work out the specifics > on each individual platform. Ant can bootstrap non-standard tasks (i.e. fetch and run) without requiring the user to install them. I'm not suggesting that Ant is an appropriate way to build the native code, just that there's ways to do it without forcing the user to install ant extensions manually. Here's a snippet for bootstrapping the maven-artifact-ant plugin in a build.xml file: ... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080122/fe76b6ba/attachment-0004.html From ajmas at sympatico.ca Tue Jan 22 18:23:26 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 20:23:26 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. > > Anyone on the list ever use autoconf and automake? We already use autoconf. The configure script is the result of running autoconf, taking configure.in as input. Andre From jamesbrannan at earthlink.net Tue Jan 22 20:46:47 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Tue, 22 Jan 2008 22:46:47 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> I did notice in your printout some inconsistencies in the readings, albeit not nearly what I experienced. Were you able to keep the rate of events constant? I was able to keep them very constant this time when I tested. Duplicated the test today. This time I removed the cadence magnet so that DSR event was never raised (circuit was never closed for DSR). I also didnt use a dongle. Only CTS events would be raised this time. Same results, RXTX would not consistently raise CTS events on my Windows XP, the Sun Comm API would. Also, I redid the Linux test, same results,RXTX performed remarkably. So, I'm trying to think what the next step would be. I suppose I should try it using another PC, however, it seems to me that if it was my operating system/computer setup Sun's would have a problem too. I'm thinking/hoping as OS X is really BSD, that it should work on OS X, though I wont know until this weekend. What would you suggest as the next step I should take? Results follow, same code as before. The difference is striking. When I watch the RXTX on windows, its as if Windows just isnt registering events at all for a second, then suddenly deciding to register events for a second or so, not register events, register events...like something is blocking or hanging. My next step is to figure out how to build the windows dll, and add in some debugging code to it, unless you think that's not worthwhile at this point. RXTX Windows: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201055567796E12Speed: 6.273481595715637E-9 cts change: 9688.0Speed: 0.7777456647398844 cts change: 312.0Speed: 24.150000000000002 cts change: 2657.0Speed: 2.8358298833270608 cts change: 640.0Speed: 11.773125 cts change: 2110.0Speed: 3.570995260663507 cts change: 312.0Speed: 24.150000000000002 cts change: 3360.0Speed: 2.2425 cts change: 5546.0Speed: 1.3586007933645872 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 5860.0Speed: 1.28580204778157 cts change: 937.0Speed: 8.041408751334044 cts change: 625.0Speed: 12.05568 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 625.0Speed: 12.05568 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 938.0Speed: 8.032835820895523 cts change: 1250.0Speed: 6.02784 cts change: 17265.0Speed: 0.4364205039096438 cts change: 3125.0Speed: 2.411136 cts change: 2500.0Speed: 3.01392 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 625.0Speed: 12.05568 cts change: 7032.0Speed: 1.0715017064846417 cts change: 625.0Speed: 12.05568 cts change: 8593.0Speed: 0.8768532526475038 cts change: 2907.0Speed: 2.5919504643962847 cts change: 1953.0Speed: 3.8580645161290326 cts change: 2578.0Speed: 2.9227307990690456 cts change: 3203.0Speed: 2.352419606618795 cts change: 2891.0Speed: 2.6062953995157385 cts change: 312.0Speed: 24.150000000000002 cts change: 5078.0Speed: 1.4838125246159906 cts change: 3516.0Speed: 2.1430034129692834 cts change: 2891.0Speed: 2.6062953995157385 cts change: 3515.0Speed: 2.1436130867709817 cts change: 313.0Speed: 24.072843450479233 cts change: 2265.0Speed: 3.3266225165562915 cts change: 313.0Speed: 24.072843450479233 cts change: 2578.0Speed: 2.9227307990690456 Sun's Comm DLL Windows ============================================================= cts change: 1.201055798875E12Speed: 6.27348038871938E-9 cts change: 421.0Speed: 17.897387173396677 cts change: 344.0Speed: 21.903488372093022 cts change: 328.0Speed: 22.971951219512196 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 297.0Speed: 25.36969696969697 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 282.0Speed: 26.719148936170214 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 328.0Speed: 22.971951219512196 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 RXTX Linux: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201052778098E12Speed: 6.2734961671977396E-9 cts change: 408.0Speed: 18.46764705882353 cts change: 372.0Speed: 20.25483870967742 cts change: 332.0Speed: 22.695180722891568 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 296.0Speed: 25.455405405405408 cts change: 292.0Speed: 25.804109589041097 cts change: 304.0Speed: 24.785526315789475 cts change: 292.0Speed: 25.804109589041097 cts change: 300.0Speed: 25.116 cts change: 304.0Speed: 24.785526315789475 cts change: 304.0Speed: 24.785526315789475 cts change: 316.0Speed: 23.844303797468356 cts change: 296.0Speed: 25.455405405405408 cts change: 304.0Speed: 24.785526315789475 cts change: 308.0Speed: 24.463636363636365 cts change: 300.0Speed: 25.116 cts change: 316.0Speed: 23.844303797468356 cts change: 305.0Speed: 24.704262295081968 cts change: 307.0Speed: 24.543322475570033 cts change: 312.0Speed: 24.150000000000002 cts change: 300.0Speed: 25.116 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 315.0Speed: 23.92 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 313.0Speed: 24.072843450479233 cts change: 319.0Speed: 23.620062695924766 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 324.0Speed: 23.255555555555556 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 328.0Speed: 22.971951219512196 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 328.0Speed: 22.971951219512196 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 313.0Speed: 24.072843450479233 cts change: 303.0Speed: 24.867326732673266 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 311.0Speed: 24.227652733118973 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 304.0Speed: 24.785526315789475 From tjarvi at qbang.org Tue Jan 22 21:01:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Jan 2008 21:01:25 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Message-ID: On Tue, 22 Jan 2008, James Brannan wrote: > I did notice in your printout some inconsistencies in the readings, albeit > not nearly what I experienced. Were you able to keep the rate of events > constant? I was not able to keep a constant rate as the timing showed. But as I watched the printout, nothing unexpected was observed. I'll need to build a opamp circuit on a breadboard to be more consistant. I've asked a few questions that I'll repeat now. 1) Is there more code than you posted in your tests? The code you posted does not even compile. 2) Are you using an onboard UART or a USB dongle? 3) could you provide a link to the exact rxtx library you are using? What I see is sane behavior that does not agree with your observations which amount to ~5 or more missed events. I certainly would see that while playing 'morse code' on a breakout box. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Thu Jan 24 11:35:02 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 24 Jan 2008 11:35:02 -0700 Subject: [Rxtx] macos compilation In-Reply-To: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> References: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> Message-ID: <2251ead40801241035k13765fedk8f523695be2b1122@mail.gmail.com> On 1/22/08, Andre-John Mas wrote: > > On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > > > > > Configuration appears to be where we are spending most of our time, > > > in the maintenance cycle. There has got to be a better way. Maven? > > > Ant? Suggestions? > > > > If there are better tools to dealing with the building of native code > > on different platforms, then I am not aware of them. > > > > Anyone on the list ever use autoconf and automake? > > We already use autoconf. The configure script is the result of running > autoconf, taking configure.in as input. I've been following the fight for "better autoconf/automake" since about 1997 - it starts to remind an old joke of IT managers of the day (1960s to 1990s) "choosing ${other-os} over Unix" with the punchline being "what part of the message you don't understand?" > Andre --vt From slacorte at ozengineering.com Thu Jan 24 18:05:22 2008 From: slacorte at ozengineering.com (Steven La Corte) Date: Thu, 24 Jan 2008 17:05:22 -0800 (PST) Subject: [Rxtx] rxtx solaris 2.9 SIGSEGV Message-ID: <448113.19444.qm@web412.biz.mail.mud.yahoo.com> We are using rxtx 2.1.7 in a Tomcat 5.5.7 servlet, that is running in Solaris 9 (SunOS 2.9). Our servlet opens 10 threads, and when a request is received, it opens a port, a readThr and writes and receives data from/to a serial port on a digi port server. The readThr is closed when processing is completed, and the port is closed. The servlet receives a request from a client every minute. The client is a cron tab application. The native code for the solaris was downloaded from the rxtx site and labelled for 32bit solaris 2.8. No changes or patches have been applied to the downloaded files (jar or .so). The servlet starts up, opens ports and successfully reads, writes and closes the port to the digi port server (and field devices connected to the digig port server) for a period of time (about one hour). Then we will notice that read attempts begin to not complete and appear to throw interrupt exceptions. Closing and reopening the port doesn't help, no data is still received. And finally, after some time, Tomcat will crash due to a SIGSEGV. I am attaching two typical HotSpot dumps. Any info that can be shared with us will be greatly appreciated. Thanks, Steve La Corte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1559.log Type: application/octet-stream Size: 8899 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid9786.log Type: application/octet-stream Size: 9310 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0005.obj From rspencer at FuelQuest.com Fri Jan 25 08:19:16 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Fri, 25 Jan 2008 09:19:16 -0600 Subject: [Rxtx] RXTX 2.1-7 [latest]: getting "Bad file descriptor in nativeavailable" exception Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702FA736E@fqmx03.fuelquest.com> Hello, I am getting several exceptions while using RXTX 2.1-7 [commapi branch latest]. I am running RXTX under Linux version 2.6.9-42.ELsmp (bhcompile at hs20-bc1-1.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Wed Jul 12 23:27:17 EDT 2006 I am catching the following exception: 2008-01-25 00:02:57 ERROR There was an issue trying to read from the port's [/dev/ttyS6] InputStream! java.io.IOException: Bad file descriptor in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1488) at com.testing.readInputStream(ModemTalker.java:926) Also, I'm getting (sent to STDOUT - they may or may not be related) RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS4: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS5: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS4: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists Here is the method that checks the stream's availablity from the port and read it ... private synchronized void readInputStream() { int x = 0; try { while (isReadyOrConnected() && (getInputStream().available() > 0) && ((x = getInputStream().read()) != -1)) { setReading(true); getOutputBuffer().append((char) x); } setReading(false); } catch (IOException e) { setReading(false); log.error("There was an issue trying to read from the port's [" + getPortName() + "] InputStream!", e); return; } } Does anyone have any ideas for fixes / workarounds? I've checked and my code close all streams and ports after every use so I don't think the lock errors could be because of it (as a secondary check I have my code make sure it is not owned). Since my code retries it seems to work after that, however I would like my code to be exceptional (exception-less). :-) Please provide assistance if you know what's up with it. Thanks. Rodney Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080125/323fc1e3/attachment.html From james.i.brannan at lmco.com Fri Jan 25 15:39:03 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 25 Jan 2008 17:39:03 -0500 Subject: [Rxtx] Sun vs. Rxtx and now MAC question Message-ID: Apparently my last email never made it to the list. To answer Trent's questions regarding my tests.... 1) I did duplicate the results using a UART and not dongle two days ago. 2) I promise that's the logic in the event handler and the main method was the only part of code running, nothing else going on 3) I reran without the cadence magnet (no DSR) - only one signal coming to RXTX - and got the same strange results But, I replaced my company Dell laptop for a Mac. Now I have a whole new issue....I read the threads on 2.1.8 etc. Being lazy for now, if I do the following below is that sufficient to run 2.1.7 on my Mac (I got the f.a.q. lock problem)... sudo mkdir /var/lock and sudo chmod 1777 /var/lock After testing on Mac I'll go back to trying to figure out windoz.....I'm installing a dual-boot on my Mac (Steve Jobs please forgive me)...so I'll be able to test XP more. James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080125/8d9de59f/attachment-0001.html From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0025.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0024.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0024.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0024.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0023.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0023.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0020.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0019.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0019.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0019.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0038.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0039.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0019.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0018.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0018.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0018.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0018.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0018.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0018.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0018.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0017.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0017.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0017.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0017.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0017.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0017.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0013.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0010.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0010.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0010.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0009.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0009.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment-0006.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From ajmas at sympatico.ca Tue Jan 22 07:16:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 09:16:10 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On 20-Jan-08, at 07:53 , Dr. Douglas Lyon wrote: > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? I was thinking about this, and while Maven and Ant are great tools, they only solve the Java side of things. The building of RXTX for the most part involves native code and this is where tools such as Make and Configure have their strengths. They may not necessarily be the greatest things since slide bread, but trying to deal with differences in architectures and assumptions of different platforms is quite an arduous ordeal. If there are better tools to dealing with the building of native code on different platforms, then I am not aware of them. It should be noted that I have once made a native build file with Ant, but it depended on non-standard tasks, meaning something else to install, and it wouldn't have dealt well with trying to work out the specifics on each individual platform. Andre From james.i.brannan at lmco.com Tue Jan 22 08:19:32 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 10:19:32 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Regarding the not reproducable...is it possible then the problem might lie with the RTS? Remember, what's happening is that the RTS is powering the CTS. It doesn't seem likely, though, as all the sensors are doing is opening/closing the flow between RTS and CTS. I will try this on another pc and see if I get the same behavior. From james.i.brannan at lmco.com Tue Jan 22 09:32:40 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 11:32:40 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Sorry about the code...I a little bit of unused code from it to make it shorter. Remember, I experienced the same results using RXTX without the dongle. Errr....oops, I just realized something though, we are *NOT* doing the same test. Seems I forgot to unattach the DSR sensor....so in fact the RXTX code is getting both CTS and DSR signals (I'm just not handling it in my listener)....sorry about that detail. I will have to test again tonight one with both sensors, one with only CTS. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, January 22, 2008 11:27 AM To: Brannan, James I (N-Fenestra) Cc: tjarvi at qbang.org Subject: RE: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm I really doubt it. Microsoft and Sun did _not_ get along back then. Remember the antitrust case. Microsoft would not share undocumented APIs. The serial API is fairly close to being 'on the hardware' as it is. There would not be much underneath. I have two and a half suspicions. The first is that for some reason the voltage was not enough to trigger cts consistantly. The second is you used a USB dongle with rxtx and it's kernel driver isn't doing what is expected. The half suspicion is your code did not compile. Are you sure we are trying the exact same test? I had to add the port enumeration to get CommPortIdentifier. The test of cts was unchanged. Perhaps you are doing something with a GUI and by chance, rxtx is being impacted. btw, I was just triggering from a live wire from the serial port too. The only difference is I used only a wire between the pins (in a breakout box). Why don't you mail me the dll you used just so I can verify that it wasnt something different in the native code. I doubt it but we can try. On Tue, 22 Jan 2008, Brannan, James I (N-Fenestra) wrote: > Dumb question...is it possible that Sun is accessing the underlying port > bypassing the layer RXTX uses? > > -----Original Message----- > From: Brannan, James I (N-Fenestra) > Sent: Tuesday, January 22, 2008 10:20 AM > To: 'rxtx at qbang.org' > Cc: 'tjarvi at qbang.org' > Subject: Re: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm > > Regarding the not reproducable...is it possible then the problem might > lie with the RTS? Remember, what's happening is that the RTS is > powering the CTS. It doesn't seem likely, though, as all the sensors > are doing is opening/closing the flow between RTS and CTS. I will try > this on another pc and see if I get the same behavior. > From Bob_Jacobsen at lbl.gov Tue Jan 22 09:54:22 2008 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 22 Jan 2008 08:54:22 -0800 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: At 10:19 AM -0500 1/22/08, Brannan, James I (N-Fenestra) wrote: >Regarding the not reproducable...is it possible then the problem might >lie with the RTS? Remember, what's happening is that the RTS is >powering the CTS. It doesn't seem likely, though, as all the sensors >are doing is opening/closing the flow between RTS and CTS. I will try >this on another pc and see if I get the same behavior. Make sure that you have all the flow control options explicitly disabled in your code, so that there's no "automagic" attempts to change the various control leads. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Tue Jan 22 10:25:33 2008 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 22 Jan 2008 09:25:33 -0800 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. Anyone on the list ever use autoconf and automake? > It should be noted that I have once made a native build file with Ant, > but it depended on non-standard tasks, meaning something else to > install, > and it wouldn't have dealt well with trying to work out the specifics > on each individual platform. Ant can bootstrap non-standard tasks (i.e. fetch and run) without requiring the user to install them. I'm not suggesting that Ant is an appropriate way to build the native code, just that there's ways to do it without forcing the user to install ant extensions manually. Here's a snippet for bootstrapping the maven-artifact-ant plugin in a build.xml file: ... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080122/fe76b6ba/attachment-0005.html From ajmas at sympatico.ca Tue Jan 22 18:23:26 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 20:23:26 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. > > Anyone on the list ever use autoconf and automake? We already use autoconf. The configure script is the result of running autoconf, taking configure.in as input. Andre From jamesbrannan at earthlink.net Tue Jan 22 20:46:47 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Tue, 22 Jan 2008 22:46:47 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> I did notice in your printout some inconsistencies in the readings, albeit not nearly what I experienced. Were you able to keep the rate of events constant? I was able to keep them very constant this time when I tested. Duplicated the test today. This time I removed the cadence magnet so that DSR event was never raised (circuit was never closed for DSR). I also didnt use a dongle. Only CTS events would be raised this time. Same results, RXTX would not consistently raise CTS events on my Windows XP, the Sun Comm API would. Also, I redid the Linux test, same results,RXTX performed remarkably. So, I'm trying to think what the next step would be. I suppose I should try it using another PC, however, it seems to me that if it was my operating system/computer setup Sun's would have a problem too. I'm thinking/hoping as OS X is really BSD, that it should work on OS X, though I wont know until this weekend. What would you suggest as the next step I should take? Results follow, same code as before. The difference is striking. When I watch the RXTX on windows, its as if Windows just isnt registering events at all for a second, then suddenly deciding to register events for a second or so, not register events, register events...like something is blocking or hanging. My next step is to figure out how to build the windows dll, and add in some debugging code to it, unless you think that's not worthwhile at this point. RXTX Windows: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201055567796E12Speed: 6.273481595715637E-9 cts change: 9688.0Speed: 0.7777456647398844 cts change: 312.0Speed: 24.150000000000002 cts change: 2657.0Speed: 2.8358298833270608 cts change: 640.0Speed: 11.773125 cts change: 2110.0Speed: 3.570995260663507 cts change: 312.0Speed: 24.150000000000002 cts change: 3360.0Speed: 2.2425 cts change: 5546.0Speed: 1.3586007933645872 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 5860.0Speed: 1.28580204778157 cts change: 937.0Speed: 8.041408751334044 cts change: 625.0Speed: 12.05568 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 625.0Speed: 12.05568 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 938.0Speed: 8.032835820895523 cts change: 1250.0Speed: 6.02784 cts change: 17265.0Speed: 0.4364205039096438 cts change: 3125.0Speed: 2.411136 cts change: 2500.0Speed: 3.01392 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 625.0Speed: 12.05568 cts change: 7032.0Speed: 1.0715017064846417 cts change: 625.0Speed: 12.05568 cts change: 8593.0Speed: 0.8768532526475038 cts change: 2907.0Speed: 2.5919504643962847 cts change: 1953.0Speed: 3.8580645161290326 cts change: 2578.0Speed: 2.9227307990690456 cts change: 3203.0Speed: 2.352419606618795 cts change: 2891.0Speed: 2.6062953995157385 cts change: 312.0Speed: 24.150000000000002 cts change: 5078.0Speed: 1.4838125246159906 cts change: 3516.0Speed: 2.1430034129692834 cts change: 2891.0Speed: 2.6062953995157385 cts change: 3515.0Speed: 2.1436130867709817 cts change: 313.0Speed: 24.072843450479233 cts change: 2265.0Speed: 3.3266225165562915 cts change: 313.0Speed: 24.072843450479233 cts change: 2578.0Speed: 2.9227307990690456 Sun's Comm DLL Windows ============================================================= cts change: 1.201055798875E12Speed: 6.27348038871938E-9 cts change: 421.0Speed: 17.897387173396677 cts change: 344.0Speed: 21.903488372093022 cts change: 328.0Speed: 22.971951219512196 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 297.0Speed: 25.36969696969697 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 282.0Speed: 26.719148936170214 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 328.0Speed: 22.971951219512196 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 RXTX Linux: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201052778098E12Speed: 6.2734961671977396E-9 cts change: 408.0Speed: 18.46764705882353 cts change: 372.0Speed: 20.25483870967742 cts change: 332.0Speed: 22.695180722891568 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 296.0Speed: 25.455405405405408 cts change: 292.0Speed: 25.804109589041097 cts change: 304.0Speed: 24.785526315789475 cts change: 292.0Speed: 25.804109589041097 cts change: 300.0Speed: 25.116 cts change: 304.0Speed: 24.785526315789475 cts change: 304.0Speed: 24.785526315789475 cts change: 316.0Speed: 23.844303797468356 cts change: 296.0Speed: 25.455405405405408 cts change: 304.0Speed: 24.785526315789475 cts change: 308.0Speed: 24.463636363636365 cts change: 300.0Speed: 25.116 cts change: 316.0Speed: 23.844303797468356 cts change: 305.0Speed: 24.704262295081968 cts change: 307.0Speed: 24.543322475570033 cts change: 312.0Speed: 24.150000000000002 cts change: 300.0Speed: 25.116 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 315.0Speed: 23.92 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 313.0Speed: 24.072843450479233 cts change: 319.0Speed: 23.620062695924766 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 324.0Speed: 23.255555555555556 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 328.0Speed: 22.971951219512196 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 328.0Speed: 22.971951219512196 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 313.0Speed: 24.072843450479233 cts change: 303.0Speed: 24.867326732673266 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 311.0Speed: 24.227652733118973 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 304.0Speed: 24.785526315789475 From tjarvi at qbang.org Tue Jan 22 21:01:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Jan 2008 21:01:25 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Message-ID: On Tue, 22 Jan 2008, James Brannan wrote: > I did notice in your printout some inconsistencies in the readings, albeit > not nearly what I experienced. Were you able to keep the rate of events > constant? I was not able to keep a constant rate as the timing showed. But as I watched the printout, nothing unexpected was observed. I'll need to build a opamp circuit on a breadboard to be more consistant. I've asked a few questions that I'll repeat now. 1) Is there more code than you posted in your tests? The code you posted does not even compile. 2) Are you using an onboard UART or a USB dongle? 3) could you provide a link to the exact rxtx library you are using? What I see is sane behavior that does not agree with your observations which amount to ~5 or more missed events. I certainly would see that while playing 'morse code' on a breakout box. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Thu Jan 24 11:35:02 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 24 Jan 2008 11:35:02 -0700 Subject: [Rxtx] macos compilation In-Reply-To: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> References: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> Message-ID: <2251ead40801241035k13765fedk8f523695be2b1122@mail.gmail.com> On 1/22/08, Andre-John Mas wrote: > > On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > > > > > Configuration appears to be where we are spending most of our time, > > > in the maintenance cycle. There has got to be a better way. Maven? > > > Ant? Suggestions? > > > > If there are better tools to dealing with the building of native code > > on different platforms, then I am not aware of them. > > > > Anyone on the list ever use autoconf and automake? > > We already use autoconf. The configure script is the result of running > autoconf, taking configure.in as input. I've been following the fight for "better autoconf/automake" since about 1997 - it starts to remind an old joke of IT managers of the day (1960s to 1990s) "choosing ${other-os} over Unix" with the punchline being "what part of the message you don't understand?" > Andre --vt From slacorte at ozengineering.com Thu Jan 24 18:05:22 2008 From: slacorte at ozengineering.com (Steven La Corte) Date: Thu, 24 Jan 2008 17:05:22 -0800 (PST) Subject: [Rxtx] rxtx solaris 2.9 SIGSEGV Message-ID: <448113.19444.qm@web412.biz.mail.mud.yahoo.com> We are using rxtx 2.1.7 in a Tomcat 5.5.7 servlet, that is running in Solaris 9 (SunOS 2.9). Our servlet opens 10 threads, and when a request is received, it opens a port, a readThr and writes and receives data from/to a serial port on a digi port server. The readThr is closed when processing is completed, and the port is closed. The servlet receives a request from a client every minute. The client is a cron tab application. The native code for the solaris was downloaded from the rxtx site and labelled for 32bit solaris 2.8. No changes or patches have been applied to the downloaded files (jar or .so). The servlet starts up, opens ports and successfully reads, writes and closes the port to the digi port server (and field devices connected to the digig port server) for a period of time (about one hour). Then we will notice that read attempts begin to not complete and appear to throw interrupt exceptions. Closing and reopening the port doesn't help, no data is still received. And finally, after some time, Tomcat will crash due to a SIGSEGV. I am attaching two typical HotSpot dumps. Any info that can be shared with us will be greatly appreciated. Thanks, Steve La Corte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1559.log Type: application/octet-stream Size: 8899 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0006.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid9786.log Type: application/octet-stream Size: 9310 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0007.obj From rspencer at FuelQuest.com Fri Jan 25 08:19:16 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Fri, 25 Jan 2008 09:19:16 -0600 Subject: [Rxtx] RXTX 2.1-7 [latest]: getting "Bad file descriptor in nativeavailable" exception Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702FA736E@fqmx03.fuelquest.com> Hello, I am getting several exceptions while using RXTX 2.1-7 [commapi branch latest]. I am running RXTX under Linux version 2.6.9-42.ELsmp (bhcompile at hs20-bc1-1.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Wed Jul 12 23:27:17 EDT 2006 I am catching the following exception: 2008-01-25 00:02:57 ERROR There was an issue trying to read from the port's [/dev/ttyS6] InputStream! java.io.IOException: Bad file descriptor in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1488) at com.testing.readInputStream(ModemTalker.java:926) Also, I'm getting (sent to STDOUT - they may or may not be related) RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS4: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS5: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS4: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists Here is the method that checks the stream's availablity from the port and read it ... private synchronized void readInputStream() { int x = 0; try { while (isReadyOrConnected() && (getInputStream().available() > 0) && ((x = getInputStream().read()) != -1)) { setReading(true); getOutputBuffer().append((char) x); } setReading(false); } catch (IOException e) { setReading(false); log.error("There was an issue trying to read from the port's [" + getPortName() + "] InputStream!", e); return; } } Does anyone have any ideas for fixes / workarounds? I've checked and my code close all streams and ports after every use so I don't think the lock errors could be because of it (as a secondary check I have my code make sure it is not owned). Since my code retries it seems to work after that, however I would like my code to be exceptional (exception-less). :-) Please provide assistance if you know what's up with it. Thanks. Rodney Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080125/323fc1e3/attachment-0002.html From james.i.brannan at lmco.com Fri Jan 25 15:39:03 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 25 Jan 2008 17:39:03 -0500 Subject: [Rxtx] Sun vs. Rxtx and now MAC question Message-ID: Apparently my last email never made it to the list. To answer Trent's questions regarding my tests.... 1) I did duplicate the results using a UART and not dongle two days ago. 2) I promise that's the logic in the event handler and the main method was the only part of code running, nothing else going on 3) I reran without the cadence magnet (no DSR) - only one signal coming to RXTX - and got the same strange results But, I replaced my company Dell laptop for a Mac. Now I have a whole new issue....I read the threads on 2.1.8 etc. Being lazy for now, if I do the following below is that sufficient to run 2.1.7 on my Mac (I got the f.a.q. lock problem)... sudo mkdir /var/lock and sudo chmod 1777 /var/lock After testing on Mac I'll go back to trying to figure out windoz.....I'm installing a dual-boot on my Mac (Steve Jobs please forgive me)...so I'll be able to test XP more. James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080125/8d9de59f/attachment-0002.html From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0026.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0025.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0025.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0025.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0024.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0024.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0021.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0020.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0020.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0020.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0040.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0041.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0020.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0019.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0019.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0019.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0019.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0019.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0019.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0019.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0018.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0018.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0018.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0018.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0018.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0018.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0014.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0011.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0011.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0011.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0010.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0010.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Sat, 19 Jan 2008, Andre-John Mas wrote: > > On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> >> The Mac OS X case was probably a hack at the time. One thing that would be >> good to check as you have the machine: The configure script should work >> without JAVA_HOME being set and with java/javac on your path. >> >> There is code in configure that overides the path if JAVA_HOME is set. It >> determines JPATH. >> >> If that's default to have JAVA_HOME set on Mac OS X, then don't worry. > > Hi, > > I tested with both JAVA_HOME set and unset. Configure will run perfectly if > the variable is not set. On the other hand it is hit and miss whether it > works when it is set. Removing the special case for the Mac results in > configure that works in both cases. It would appear that JPATH is calculated > correctly when it is not set and when JAVA_HOME is set it will take that > value. > > Currently I have tested having: > > JAVAINCLUDEDIR=$JPATH/include > > on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can > see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ > on MacOS X that conforms properly to the directory structure and I am not > even sure that we should be supporting JDK 1.3 any more on the Mac. From what > I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider > support for MacOS X 10.2, except as a special case, which could be defined by > a configure option if need be. > You suggestion sounds good to me. My only thought is that old Macs don't always go away. My brother is an example. He was given an old Mac that can't be upgraded. Is there anything we can do now to help people in the future? Perhaps the solution is as simple as putting a entry in the wiki that lists which version of rxtx to download for a given Mac OS. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 19 13:09:33 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 15:09:33 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 19-Jan-08, at 13:32 , Trent Jarvi wrote: > On Sat, 19 Jan 2008, Andre-John Mas wrote: > >> >> On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >>> The Mac OS X case was probably a hack at the time. One thing that >>> would be good to check as you have the machine: The configure >>> script should work without JAVA_HOME being set and with java/javac >>> on your path. >>> There is code in configure that overides the path if JAVA_HOME is >>> set. It determines JPATH. >>> If that's default to have JAVA_HOME set on Mac OS X, then don't >>> worry. >> >> Hi, >> >> I tested with both JAVA_HOME set and unset. Configure will run >> perfectly if the variable is not set. On the other hand it is hit >> and miss whether it works when it is set. Removing the special case >> for the Mac results in configure that works in both cases. It would >> appear that JPATH is calculated correctly when it is not set and >> when JAVA_HOME is set it will take that value. >> >> Currently I have tested having: >> >> JAVAINCLUDEDIR=$JPATH/include >> >> on both MacOS X 10.4 and 10.5 and this works fine. The only >> scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The >> truth it only JDK 1.4+ on MacOS X that conforms properly to the >> directory structure and I am not even sure that we should be >> supporting JDK 1.3 any more on the Mac. From what I can tell JDK >> 1.4 came with MacOS X 10.3, so I doubt we should even consider >> support for MacOS X 10.2, except as a special case, which could be >> defined by a configure option if need be. >> > > You suggestion sounds good to me. My only thought is that old Macs > don't always go away. My brother is an example. He was given an > old Mac that can't be upgraded. Is there anything we can do now to > help people in the future? > > Perhaps the solution is as simple as putting a entry in the wiki > that lists which version of rxtx to download for a given Mac OS. The other solution is to displace deprecated stuff to a configure option, so that we can move forward, but still provide support for people those people who need it. I am thinking, in this case: configure --mrj or configure --mac-runtime-for-java Allows building on MacOS X 10.2 and older (legacy support) 'Mac Runtime for Java' is the name given for the Java environment used by Apple, before they brought their JDK in line with the official Java reference platform. At a given point, the legacy support can be dropped, but in the meantime it provides a solution. Andre From jamesbrannan at earthlink.net Sat Jan 19 16:02:28 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 17:02:28 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <3508619.1200783748342.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Regarding the problem I'm having with RXTX handling semi-rapid CTS and DSR events.... Okay, I increased the thread priority and I removed all debugging from the RXTX code, and did a couple minimal tweaks. As advised here, I experience negligable performance differences. I wrote a very simple SerialPortListener that simply printed the current time in milliseconds, and I got the same behavior I discussed before. Steady enough for a bike computer's accuracy at least. Sun's Windows javax.comm would steadily print to stdout the cts and dsr events. RXTX would print a few values, pause, print a few values, pause, i.e. wasn't steady at all. I'm wondering if its the Monitor Thread or if its the c layer. James Brannan From jamesbrannan at earthlink.net Sat Jan 19 18:39:29 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 19:39:29 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... Any thoughts? Suns Win32 Comm: cts change: 500.0Speed: 15.069600000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 516.0Speed: 14.602325581395348 cts change: 484.0Speed: 15.567768595041322 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 485.0Speed: 15.535670103092784 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 468.0Speed: 16.1 cts change: 422.0Speed: 17.854976303317535 cts change: 391.0Speed: 19.270588235294117 cts change: 422.0Speed: 17.854976303317535 cts change: 390.0Speed: 19.32 cts change: 407.0Speed: 18.513022113022114 cts change: 421.0Speed: 17.897387173396677 cts change: 407.0Speed: 18.513022113022114 cts change: 406.0Speed: 18.55862068965517 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 454.0Speed: 16.59647577092511 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 454.0Speed: 16.59647577092511 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 0.0Speed: Infinity cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 469.0Speed: 16.065671641791045 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 438.0Speed: 17.2027397260274 cts change: 437.0Speed: 17.242105263157896 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 453.0Speed: 16.633112582781457 cts change: 453.0Speed: 16.633112582781457 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 cts change: 453.0Speed: 16.633112582781457 cts change: 422.0Speed: 17.854976303317535 cts change: 15.0Speed: 502.32 cts change: 422.0Speed: 17.854976303317535 cts change: 438.0Speed: 17.2027397260274 cts change: 422.0Speed: 17.854976303317535 cts change: 437.0Speed: 17.242105263157896 cts change: 438.0Speed: 17.2027397260274 ------------------------------------------------------------------ RXTX: cts change: 2500.0Speed: 3.01392 cts change: 5313.0Speed: 1.4181818181818182 cts change: 7734.0Speed: 0.974243599689682 cts change: 1172.0Speed: 6.42901023890785 cts change: 5703.0Speed: 1.3211993687532877 cts change: 859.0Speed: 8.771594877764842 cts change: 1250.0Speed: 6.02784 cts change: 8125.0Speed: 0.9273600000000001 cts change: 2500.0Speed: 3.01392 cts change: 13594.0Speed: 0.5542739443872297 cts change: 2891.0Speed: 2.6062953995157385 cts change: 1250.0Speed: 6.02784 cts change: 5406.0Speed: 1.3937846836847947 cts change: 1250.0Speed: 6.02784 cts change: 3359.0Speed: 2.243167609407562 cts change: 2188.0Speed: 3.443692870201097 cts change: 3125.0Speed: 2.411136 cts change: 10078.0Speed: 0.7476483429251836 cts change: 1016.0Speed: 7.416141732283465 cts change: 1718.0Speed: 4.385797438882421 cts change: 5704.0Speed: 1.320967741935484 cts change: 2812.0Speed: 2.679516358463727 cts change: 781.0Speed: 9.64763124199744 cts change: 3047.0Speed: 2.4728585493928454 cts change: 6094.0Speed: 1.2364292746964227 cts change: 1172.0Speed: 6.42901023890785 cts change: 2031.0Speed: 3.7098966026587887 code: package com.intervaltrack.serialio; //import javax.comm.*; import gnu.io.*; import java.util.TooManyListenersException; public class SerialConnection2 implements SerialPortEventListener { private SerialPort serialPort; private boolean oldCTSValue = false; private double oldValue = 0; public SerialConnection2() { try { this.strComPortAsString ="COM4"; this.setComPortIdentifier(this.strComPortAsString); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } catch(Exception ex) { ex.printStackTrace(); } } public void serialEvent(SerialPortEvent e) { if(e.getEventType() == SerialPortEvent.CTS) { //avoiding the instantaneous event of and only counting //rotation events if(e.getNewValue()==false && oldCTSValue == true) { double newTime = System.currentTimeMillis(); System.out.print("cts change: " + (newTime-this.oldValue)); System.out.print("Speed: " + ((double)3.6 * (double)2093) / (double)(newTime-oldValue) + "\n"); oldValue = newTime; } oldCTSValue = e.getNewValue(); } } public static void main(String[] args) { SerialConnection2 x = new SerialConnection2(); } } From tjarvi at qbang.org Sat Jan 19 19:18:40 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:18:40 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and > I'll stop posting. Unless there is something I am just not seeing, > there is definitly something going on with RXTX's events...and look at > Sun's results below, so I really dont think blaming it on Windoze is a > valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on > a Dell Latitude D620 laptop using a serial-port/usb converter - test can > be duplicated straight serial though). BTW, Sun's Windows comm api > impl. is spot-on, even in my GUI program with a music thread, a video > thread, etc. But using Sun's outdated windows version isnt an option, > as I am developing a cross-platform application and need to run on a > mac...and using some embedded device to do the processing isnt an > option, as the whole "niche" of this product is its simplicity and > cheapness. So, I'm trying to help out here and figure out why I'm > getting this poor performance from RXTX, despite my limited to > non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the > test program (pedaling as close to 17 mph as I could) Sun is dead on, > RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 516.0Speed: 14.602325581395348 > cts change: 484.0Speed: 15.567768595041322 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 485.0Speed: 15.535670103092784 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 468.0Speed: 16.1 > cts change: 422.0Speed: 17.854976303317535 > cts change: 391.0Speed: 19.270588235294117 > cts change: 422.0Speed: 17.854976303317535 > cts change: 390.0Speed: 19.32 > cts change: 407.0Speed: 18.513022113022114 > cts change: 421.0Speed: 17.897387173396677 > cts change: 407.0Speed: 18.513022113022114 > cts change: 406.0Speed: 18.55862068965517 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 454.0Speed: 16.59647577092511 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 454.0Speed: 16.59647577092511 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 0.0Speed: Infinity > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 469.0Speed: 16.065671641791045 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 438.0Speed: 17.2027397260274 > cts change: 437.0Speed: 17.242105263157896 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 453.0Speed: 16.633112582781457 > cts change: 453.0Speed: 16.633112582781457 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > cts change: 453.0Speed: 16.633112582781457 > cts change: 422.0Speed: 17.854976303317535 > cts change: 15.0Speed: 502.32 > cts change: 422.0Speed: 17.854976303317535 > cts change: 438.0Speed: 17.2027397260274 > cts change: 422.0Speed: 17.854976303317535 > cts change: 437.0Speed: 17.242105263157896 > cts change: 438.0Speed: 17.2027397260274 > ------------------------------------------------------------------ > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > > code: > > package com.intervaltrack.serialio; > > //import javax.comm.*; > import gnu.io.*; > import java.util.TooManyListenersException; > > > public class SerialConnection2 implements SerialPortEventListener > { > > private SerialPort serialPort; > private boolean oldCTSValue = false; > > private double oldValue = 0; > > public SerialConnection2() > { > try > { > this.strComPortAsString ="COM4"; > > this.setComPortIdentifier(this.strComPortAsString); > serialPort = (SerialPort)portID.open("IntervalTrack", 0); > serialPort.setSerialPortParams(9600, > SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > //need to notify on DSR and CTS > > serialPort.notifyOnDSR(true); > serialPort.notifyOnCTS(true); > serialPort.addEventListener(this); > > //set dtr to false - making it negative power so can > //use as negative for the circuit > > serialPort.setDTR(false); > > //set RTS to true - making it positive so its sending power > > serialPort.setRTS(true); > > //no flow control - not needed > > //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > } > catch(Exception ex) > { > ex.printStackTrace(); > } > > } > > > public void serialEvent(SerialPortEvent e) > { > > if(e.getEventType() == SerialPortEvent.CTS) > { > //avoiding the instantaneous event of and only counting > //rotation events > > if(e.getNewValue()==false && oldCTSValue == true) > { > double newTime = System.currentTimeMillis(); > System.out.print("cts change: " + > (newTime-this.oldValue)); > System.out.print("Speed: " + ((double)3.6 * > (double)2093) > / (double)(newTime-oldValue) > + "\n"); > oldValue = newTime; > } > > oldCTSValue = e.getNewValue(); > > } > } > > > public static void main(String[] args) > { > SerialConnection2 x = new SerialConnection2(); > > } > > } I wonder if the problem is not in the timing of the event but rather the number of events. If I understand your data right, rxtx is sending about 1 in 10 of the cts events. A function generator with a frequency of about 500 ms should be able to reproduce what you are doing with your circuit/bike. I can borrow a function generator Monday night and play with this problem. It would be good to collect what we know about the issue in bugzilla if you have not already. The above can be pasted into the bug report and anything you know about Linux/Mac/Solaris if tested. I can easily see the OS being 10-20 ms off in a worse case without realtime support. The above suggests we are just swallowing events. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 19 19:44:26 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 19 Jan 2008 20:44:26 -0600 (GMT-06:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my apologies, I wish I knew more C/C++ so I could help more. James A. Brannan From tjarvi at qbang.org Sat Jan 19 19:47:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 19:47:55 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <13907.1200797066537.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Okay, I'll enter it into bugzilla as soon as I get a chance. Again, my > apologies, I wish I knew more C/C++ so I could help more. > Like I said, when people try to solve the issue themselves others often are willing to help. Thanks for putting the information into gecko. When we have a fix, we try link to the background information. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jan 20 05:53:07 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 20 Jan 2008 07:53:07 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: Hi All, Here is the stuff that Andre and I figured out about the mac: 1. unsetenv JAVA_HOME 2. unsetenv CFLAGS now configure works. If you set JAVA_HOME, use: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home Other versions of JAVA_HOME do not seem to work. For example: setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home Will not work. Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. The thinking here is that this is how programmers communicate to the configure process. Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is a perfectly reasonable way to get some programs to work. OK, the use of global CFLAGS is probably a bad idea, in general. And we, as far as I can tell, are going to run into this bug, from time to time. Can't tell you how many hours this has cost us, so far. I can tell you that we have 21 e-mails on the subject (just between Andre and I) and that we eventually had Andre log into my machine, remotely, to help debug it. Thanks Andre! >>Here is what the make files look like without and with CFLAGS set to ANSI: >>< CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>-bundle >>--- CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle The top one works, the bottom one does not. I see the -g option came out twice? Not sure why, or if that is important to correctness. I can't comment intelligently about why an ANSI build prevents make from working. I now remember why I switched to Java as a programming language! OK, here is the big question: Should we be appending the CFLAGS or replacing them? Should we be appending the JAVA_HOME or replacing it? If we are appending the CFLAGS and we find ANSI, should we be warning the programmer? I don't know configure very well, so I am not sure what the convention is for this. I sort of wish we could use a cross-platform build technology (like toybox) to take care of all this. Configuration appears to be where we are spending most of our time, in the maintenance cycle. There has got to be a better way. Maven? Ant? Suggestions? Thanks! - Doug From tjarvi at qbang.org Sun Jan 20 11:25:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 11:25:45 -0700 (MST) Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On Sun, 20 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is the stuff that Andre and I figured out > about the mac: > 1. unsetenv JAVA_HOME > 2. unsetenv CFLAGS > now configure works. > > If you set JAVA_HOME, use: > setenv JAVA_HOME > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home > > Other versions of JAVA_HOME do not seem to work. > For example: > setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Home > Will not work. > > Interestingly, if you use CFLAGS, the flags will be appended, not overwritten. > > The thinking here is that this is how programmers communicate to the configure > process. > > Trouble is, the CFLAGS (set to ANSI) will not work with our configure. ANSI is > a perfectly reasonable way to get some programs to work. > > OK, the use of global CFLAGS is probably a bad idea, in general. And we, > as far as I can tell, are going to run into this bug, from time to time. > > Can't tell you how many hours this has cost us, so far. I can tell you that > we have 21 e-mails on the subject (just between Andre and I) and that > we eventually had Andre log into my machine, remotely, to help > debug it. > > Thanks Andre! > >>> Here is what the make files look like without and with CFLAGS set to ANSI: > > > >>> < CFLAGS = -g -O2 -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 >>> -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc >>> -bundle >>> --- > CFLAGS = -ansi -D_BSD_SOURCE -O -g -mmacosx-version-min=10.4 > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -bundle > > The top one works, the bottom one does not. I see the -g option > came out twice? Not sure why, or if that is important to correctness. > > I can't comment intelligently about why an ANSI build prevents make > from working. > > I now remember why I switched to Java as a programming language! > > OK, here is the big question: Should we be appending the CFLAGS or > replacing them? > Should we be appending the JAVA_HOME or replacing it? > > If we are appending the CFLAGS and we find ANSI, should we be warning > the programmer? > > I don't know configure very well, so I am not sure what the convention is > for this. I sort of wish we could use a cross-platform build technology > (like toybox) to take care of all this. > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? > I suspect just ANSI (C89/C99) is going to be far too limited. Not in the ansi C syntax but in the functions available. When flags are combined, the common subset of functions is used if I understand features.h correctly. rxtx could simply use _GNU_SOURCE and everthing should work. The other issue with stomping on the CFLAGS is configure options are passed to the compiler via CFLAGS. ./configure --enable-DEBUG=yes for instance. I have looked at Ant in the past. It did not have the capability required to build the native portions. I purchased the Ant book and it more or less suggested we could reinvent the autobreakage we already have in modules. Just look for JNI and you will find the fancy onramp to dirt roads. I don't have any experience with Maven. I can't find anything that suggests it would be a good choice for the native code on their web site. -- Trent Jarvi tjarvi at qbang.org From support at kartmanager.de Sun Jan 20 12:09:05 2008 From: support at kartmanager.de (Andre Geisler) Date: Sun, 20 Jan 2008 20:09:05 +0100 Subject: [Rxtx] Problems compiling rxtx under debian etch Message-ID: <47939C51.8070606@kartmanager.de> Hello, i used rxtx under Debian for about a year, without any problems. Now if have just installed a new computer with debian etch. I installed java1.5, after that, would compile and install rxtx, configuration went good, but make does not work for me. home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function 'Java_gnu_io_I2CPort_Initialize': /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: 'UTS_RELEASE' undeclared (first use in this function) /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each undeclared identifier is reported only once /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for each function it appears in.) libtool: link: `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is not a valid libtool object make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 What's the problem? regards Andr? Geisler From tjarvi at qbang.org Sun Jan 20 13:00:48 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 13:00:48 -0700 (MST) Subject: [Rxtx] Problems compiling rxtx under debian etch In-Reply-To: <47939C51.8070606@kartmanager.de> References: <47939C51.8070606@kartmanager.de> Message-ID: On Sun, 20 Jan 2008, Andre Geisler wrote: > Hello, > > i used rxtx under Debian for about a year, without any problems. > Now if have just installed a new computer with debian etch. > I installed java1.5, after that, would compile and install rxtx, > configuration went good, but make does not work for me. > > home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/.libs/I2CImp.o > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c: In function > 'Java_gnu_io_I2CPort_Initialize': > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: > 'UTS_RELEASE' undeclared (first use in this function) > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: (Each > undeclared identifier is reported only once > /home/andre/daten/download/rxtx-2.1-7r2/./src/I2CImp.c:96: error: for > each function it appears in.) > libtool: link: > `/home/andre/daten/download/rxtx-2.1-7r2/i686-pc-linux-gnu/I2CImp.lo' is > not a valid libtool object > make: *** [i686-pc-linux-gnu/librxtxI2C.la] Fehler 1 > > This should be resolved in CVS. I think you can 'cvs login' (passwd mousy) and 'cvs upgrade' You do not really need i2c. ./configure --enable_PRINTER=no will disable everything except serial support. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Sun Jan 20 16:50:09 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 18:50:09 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Now we are cooking.... The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot laptop). BTW, on both tests the jar and native library are being loaded via eclipse and run, the rxtx libs are not in the jre/jdk folders, if that makes any difference.... Here's the RXTX output on Linux....its more accurate then Sun on Windoze! Impressively accurate actually....kudos to the developer(s). But 98% of the market for a bike computer are windoze users! So please still consider it a worth-fixing bug, or at least help me take baby steps through the c code (remember I'm a j2ee serf). Again, trying to maintain constant 17kmph on my bike. BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to get the wireless modem working, it sure was impressive to have Ubuntu "just work" right out of the box. I will enter this into the bugzilla bug later when I'm on my pc. Next week I'll test on my Mac laptop. Thanks, James A. Brannan Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.200871857111E12Speed: 6.274441319764843E-9 cts change: 576.0Speed: 13.08125 cts change: 504.0Speed: 14.950000000000001 cts change: 500.0Speed: 15.069600000000001 cts change: 480.0Speed: 15.6975 cts change: 460.0Speed: 16.38 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 424.0Speed: 17.770754716981134 cts change: 416.0Speed: 18.1125 cts change: 416.0Speed: 18.1125 cts change: 424.0Speed: 17.770754716981134 cts change: 428.0Speed: 17.604672897196263 cts change: 428.0Speed: 17.604672897196263 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 424.0Speed: 17.770754716981134 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 460.0Speed: 16.38 cts change: 456.0Speed: 16.523684210526316 cts change: 448.0Speed: 16.81875 cts change: 436.0Speed: 17.28165137614679 cts change: 428.0Speed: 17.604672897196263 cts change: 432.0Speed: 17.441666666666666 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 448.0Speed: 16.81875 cts change: 456.0Speed: 16.523684210526316 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 432.0Speed: 17.441666666666666 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 444.0Speed: 16.97027027027027 cts change: 452.0Speed: 16.66991150442478 cts change: 456.0Speed: 16.523684210526316 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 432.0Speed: 17.441666666666666 cts change: 432.0Speed: 17.441666666666666 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 444.0Speed: 16.97027027027027 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 448.0Speed: 16.81875 cts change: 452.0Speed: 16.66991150442478 cts change: 436.0Speed: 17.28165137614679 cts change: 444.0Speed: 16.97027027027027 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 436.0Speed: 17.28165137614679 cts change: 440.0Speed: 17.124545454545455 cts change: 440.0Speed: 17.124545454545455 cts change: 428.0Speed: 17.60467289719626 From tjarvi at qbang.org Sun Jan 20 17:09:51 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 20 Jan 2008 17:09:51 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> References: <31834033.1200873010103.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: Thanks James, You just eliminated 80% of the code as a suspect. We now know the problem is in termios.c. Also important is any information regarding the serial port used with windows. I do not expect it to be a problem since you mention that the Sun CommAPI works. But if the serial port is a USB dongle, it is worth noting this information. The simplest case would be a traditional serial port with an onboard UART (listed in BIOS with an address and interrupt). On Sun, 20 Jan 2008, James Brannan wrote: > Now we are cooking.... > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > laptop). > > BTW, on both tests the jar and native library are being loaded via eclipse > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > difference.... > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > Impressively accurate actually....kudos to the developer(s). But 98% > of the market for a bike computer are windoze users! So please still > consider it a worth-fixing bug, or at least help me take baby steps through > the c code (remember I'm a j2ee serf). > > Again, trying to maintain constant 17kmph on my bike. > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > get the wireless modem working, it sure was impressive to have Ubuntu "just > work" right out of the box. > > I will enter this into the bugzilla bug later when I'm on my pc. > > Next week I'll test on my Mac laptop. > > Thanks, > James A. Brannan > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > cts change: 576.0Speed: 13.08125 > cts change: 504.0Speed: 14.950000000000001 > cts change: 500.0Speed: 15.069600000000001 > cts change: 480.0Speed: 15.6975 > cts change: 460.0Speed: 16.38 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 424.0Speed: 17.770754716981134 > cts change: 416.0Speed: 18.1125 > cts change: 416.0Speed: 18.1125 > cts change: 424.0Speed: 17.770754716981134 > cts change: 428.0Speed: 17.604672897196263 > cts change: 428.0Speed: 17.604672897196263 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 424.0Speed: 17.770754716981134 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 460.0Speed: 16.38 > cts change: 456.0Speed: 16.523684210526316 > cts change: 448.0Speed: 16.81875 > cts change: 436.0Speed: 17.28165137614679 > cts change: 428.0Speed: 17.604672897196263 > cts change: 432.0Speed: 17.441666666666666 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 448.0Speed: 16.81875 > cts change: 456.0Speed: 16.523684210526316 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 432.0Speed: 17.441666666666666 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 444.0Speed: 16.97027027027027 > cts change: 452.0Speed: 16.66991150442478 > cts change: 456.0Speed: 16.523684210526316 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 432.0Speed: 17.441666666666666 > cts change: 432.0Speed: 17.441666666666666 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 444.0Speed: 16.97027027027027 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 448.0Speed: 16.81875 > cts change: 452.0Speed: 16.66991150442478 > cts change: 436.0Speed: 17.28165137614679 > cts change: 444.0Speed: 16.97027027027027 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 436.0Speed: 17.28165137614679 > cts change: 440.0Speed: 17.124545454545455 > cts change: 440.0Speed: 17.124545454545455 > cts change: 428.0Speed: 17.60467289719626 > From jamesbrannan at earthlink.net Sun Jan 20 19:35:46 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sun, 20 Jan 2008 21:35:46 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <380-22008112123546468@earthlink.net> I'll rerun the test without the dongle tommorrow on Windows. The Linux code was without a dongle, as I was sick of fighting Linux installation issues over the last two days. However, I noticed the RXTX behavior both when using the dongle and not using the dongle, but just to be certain, I'll run the test again tommorrow. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: ; Trent Jarvi > Date: 1/20/2008 7:09:54 PM > Subject: Re: RXTX Vs. Java Sun Windows Javax.comm > > > Thanks James, > > You just eliminated 80% of the code as a suspect. We now know the problem > is in termios.c. > > Also important is any information regarding the serial port used with > windows. I do not expect it to be a problem since you mention that the > Sun CommAPI works. But if the serial port is a USB dongle, it is worth > noting this information. The simplest case would be a traditional serial > port with an onboard UART (listed in BIOS with an address and interrupt). > > On Sun, 20 Jan 2008, James Brannan wrote: > > > Now we are cooking.... > > > > The issue is *NOT* duplicable (is that a work...) on Linux (Ubuntu 7.1 - not sure the Linux kernel, same hardware as previous email - its a dualboot > > laptop). > > > > BTW, on both tests the jar and native library are being loaded via eclipse > > and run, the rxtx libs are not in the jre/jdk folders, if that makes any > > difference.... > > > > Here's the RXTX output on Linux....its more accurate then Sun on Windoze! > > Impressively accurate actually....kudos to the developer(s). But 98% > > of the market for a bike computer are windoze users! So please still > > consider it a worth-fixing bug, or at least help me take baby steps through > > the c code (remember I'm a j2ee serf). > > > > Again, trying to maintain constant 17kmph on my bike. > > > > BTW, sending this via my wireless modem via dhcp, gotta tell ya, after fighting unsuccessfully the last two days with Debian and Fedora installs to > > get the wireless modem working, it sure was impressive to have Ubuntu "just > > work" right out of the box. > > > > I will enter this into the bugzilla bug later when I'm on my pc. > > > > Next week I'll test on my Mac laptop. > > > > Thanks, > > James A. Brannan > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > cts change: 1.200871857111E12Speed: 6.274441319764843E-9 > > cts change: 576.0Speed: 13.08125 > > cts change: 504.0Speed: 14.950000000000001 > > cts change: 500.0Speed: 15.069600000000001 > > cts change: 480.0Speed: 15.6975 > > cts change: 460.0Speed: 16.38 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 416.0Speed: 18.1125 > > cts change: 416.0Speed: 18.1125 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 424.0Speed: 17.770754716981134 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 460.0Speed: 16.38 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 448.0Speed: 16.81875 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 428.0Speed: 17.604672897196263 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 448.0Speed: 16.81875 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 456.0Speed: 16.523684210526316 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 432.0Speed: 17.441666666666666 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 448.0Speed: 16.81875 > > cts change: 452.0Speed: 16.66991150442478 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 444.0Speed: 16.97027027027027 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 436.0Speed: 17.28165137614679 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 440.0Speed: 17.124545454545455 > > cts change: 428.0Speed: 17.60467289719626 > > From lyon at docjava.com Mon Jan 21 06:02:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 21 Jan 2008 08:02:38 -0500 Subject: [Rxtx] a maven on maven In-Reply-To: References: Message-ID: Hi All, Is there a maven on maven out there? I got a book on ant and another on maven. I say, there do seem to be a few JNI things going on in Maven (it has a plugin). But I don't know anything about it. http://maven.apache.org/maven-1.x/plugins/native/downloads.html http://www.uniontransit.com/apache/java-repository/maven/plugins/maven-native-plugin-1.2.jar When I unpacked the jar, I only saw one class; JavaSourceTool And it was really small. I saw mojo: http://mojo.codehaus.org/maven-native/native-maven-plugin/ But it is macos challenged. Perhaps configure/make is the only game in town. - Doug From mfrey at tssg.org Mon Jan 21 08:56:26 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 15:56:26 +0000 Subject: [Rxtx] Issues on Windows Installation of RxTx Message-ID: <4794C0AA.4000809@tssg.org> Hi, I have a installation issue with RxTx. I've wrote a program which reads values from the USB port and I've installed my *.dlls into the jdk/bin directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ext directory. Everything works fine with this setup. A colleague put the *.dlls into the jdk/jre/bin directory and the jdk/jre/lib/ext directory like the manual at [1] states. The problem now is that if she plugin the device to the USB port and tries to read values from the device she doesn't get any data (the length of the data is always 0). So maybe somebody has an idea what is wrong or has a tip what we should check? Thanks in advance! Best Regards, Michael [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows From sebastien.jean.rxtx at gmail.com Mon Jan 21 09:54:16 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Mon, 21 Jan 2008 17:54:16 +0100 Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: <4794C0AA.4000809@tssg.org> References: <4794C0AA.4000809@tssg.org> Message-ID: hi, I don't know if it is your issue but under windows there is a known bug of RxTx that lead to non-blocking reading if no timeout has been parametered while opening the port. In other words, each call to read on port's inputstream return immediately 0. I experienced this bug, a thread about it can be found on rxtx ml archive. Will this bug (still present in 2.1.7) be corrected in next release ? Baz Le 21 janv. 08 ? 16:56, Michael Frey a ?crit : > Hi, > > I have a installation issue with RxTx. I've wrote a program which > reads > values from the USB port and I've installed my *.dlls into the jdk/bin > directory (instead of jdk/jre/bin) and the jar file into jdk/jre/lib/ > ext > directory. Everything works fine with this setup. > > A colleague put the *.dlls into the jdk/jre/bin directory and the > jdk/jre/lib/ext directory like the manual at [1] states. The problem > now > is that if she plugin the device to the USB port and tries to read > values from the device she doesn't get any data (the length of the > data > is always 0). So maybe somebody has an idea what is wrong or has a tip > what we should check? > > Thanks in advance! > > Best Regards, > Michael > > [1] http://rxtx.qbang.org/wiki/index.php/Installation_for_Windows > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From glenn at satlantic.com Mon Jan 21 10:18:02 2008 From: glenn at satlantic.com (Glenn Davidson) Date: Mon, 21 Jan 2008 13:18:02 -0400 Subject: [Rxtx] RXTX for 64bit Windows? Message-ID: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Hi, I was looking on the RXTX site for information on the existence of a 64 bit version of the RXTX windows library. I don't believe it currently exists as a binary download. Is this correct? What would be involved in compiling the source code to create one? From mfrey at tssg.org Mon Jan 21 14:03:57 2008 From: mfrey at tssg.org (Michael Frey) Date: Mon, 21 Jan 2008 21:03:57 -0000 (GMT) Subject: [Rxtx] Issues on Windows Installation of RxTx In-Reply-To: References: <4794C0AA.4000809@tssg.org> Message-ID: <11882.87.198.209.58.1200949437.squirrel@webmail.tssg.org> Hi, > I don't know if it is your issue but under windows there is a known > bug of RxTx that lead to non-blocking reading if no timeout has been > parametered while opening the port. I don't think so, but I will check - so thanks for the help. We're both run Windows XP with SP2, Java 1.6 R3 and Netbeans 6, so the systems are quite the same besides the hardware. I have no clue why it's working at my place and not on her computer. Any ideas are welcome! Best Regards, Michael From tjarvi at qbang.org Mon Jan 21 17:55:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 17:55:08 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <2249017.1200793169779.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 19 Jan 2008, James Brannan wrote: > Hopefully this isnt considered wasting bandwidth, if so, let me know and I'll stop posting. Unless there is something I am just not seeing, there is definitly something going on with RXTX's events...and look at Sun's results below, so I really dont think blaming it on Windoze is a valid answer (BTW, 1.83 ghz, 2mg ram machine running XP Professional on a Dell Latitude D620 laptop using a serial-port/usb converter - test can be duplicated straight serial though). BTW, Sun's Windows comm api impl. is spot-on, even in my GUI program with a music thread, a video thread, etc. But using Sun's outdated windows version isnt an option, as I am developing a cross-platform application and need to run on a mac...and using some embedded device to do the processing isnt an option, as the whole "niche" of this product is its simplicity and cheapness. So, I'm trying to help out here and figure out why I'm getting this poor performance from RXTX, despite my limited to non-existant C/C++ knowledge. > > Simple stdout of Sun's Windows Comm API followed by RXTX followed by the test program (pedaling as close to 17 mph as I could) Sun is dead on, RXTS is way off.... > > Any thoughts? > > Suns Win32 Comm: > > cts change: 500.0Speed: 15.069600000000001 > cts change: 500.0Speed: 15.069600000000001 ... > > RXTX: > > cts change: 2500.0Speed: 3.01392 > cts change: 5313.0Speed: 1.4181818181818182 > cts change: 7734.0Speed: 0.974243599689682 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 5703.0Speed: 1.3211993687532877 > cts change: 859.0Speed: 8.771594877764842 > cts change: 1250.0Speed: 6.02784 > cts change: 8125.0Speed: 0.9273600000000001 > cts change: 2500.0Speed: 3.01392 > cts change: 13594.0Speed: 0.5542739443872297 > cts change: 2891.0Speed: 2.6062953995157385 > cts change: 1250.0Speed: 6.02784 > cts change: 5406.0Speed: 1.3937846836847947 > cts change: 1250.0Speed: 6.02784 > cts change: 3359.0Speed: 2.243167609407562 > cts change: 2188.0Speed: 3.443692870201097 > cts change: 3125.0Speed: 2.411136 > cts change: 10078.0Speed: 0.7476483429251836 > cts change: 1016.0Speed: 7.416141732283465 > cts change: 1718.0Speed: 4.385797438882421 > cts change: 5704.0Speed: 1.320967741935484 > cts change: 2812.0Speed: 2.679516358463727 > cts change: 781.0Speed: 9.64763124199744 > cts change: 3047.0Speed: 2.4728585493928454 > cts change: 6094.0Speed: 1.2364292746964227 > cts change: 1172.0Speed: 6.42901023890785 > cts change: 2031.0Speed: 3.7098966026587887 > > I'll need an op-amp for the function generator I wanted to try this with. It's voltage range isn't enough to trigger CTS. But I can see that your observations are not going to be reproducable. In a breakout box, I tapped a wire as fast as I could to generate a 'frequency.' The tapping is very error prone but is about 200 ms (5 Hz) between the sides of the socket. The shorter times are bouncing on the same side of the socket. But I can see the lines print out as I do it and nothing is missed as far as I can tell. Notice the times: cts change: 93.0Speed: 81.01935483870967 cts change: 79.0Speed: 95.37721518987343 cts change: 171.0Speed: 44.06315789473684 cts change: 188.0Speed: 40.07872340425532 cts change: 172.0Speed: 43.806976744186045 cts change: 187.0Speed: 40.29304812834225 cts change: 188.0Speed: 40.07872340425532 cts change: 47.0Speed: 160.31489361702128 cts change: 187.0Speed: 40.29304812834225 cts change: 438.0Speed: 17.2027397260274 cts change: 47.0Speed: 160.31489361702128 cts change: 62.0Speed: 121.52903225806452 cts change: 203.0Speed: 37.11724137931034 cts change: 188.0Speed: 40.07872340425532 cts change: 31.0Speed: 243.05806451612904 cts change: 94.0Speed: 80.15744680851064 cts change: 203.0Speed: 37.11724137931034 cts change: 109.0Speed: 69.12660550458716 cts change: 78.0Speed: 96.60000000000001 cts change: 203.0Speed: 37.11724137931034 cts change: 79.0Speed: 95.37721518987343 cts change: 187.0Speed: 40.29304812834225 cts change: 281.0Speed: 26.81423487544484 This is xp sp2 using an onboard UART. -- Trent Jarvi tjarvi at mathworks.com From tjarvi at qbang.org Mon Jan 21 19:32:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 19:32:32 -0700 (MST) Subject: [Rxtx] RXTX for 64bit Windows? In-Reply-To: <47949B8A.12914.1F7B6811@glenn.satlantic.com> References: <47949B8A.12914.1F7B6811@glenn.satlantic.com> Message-ID: On Mon, 21 Jan 2008, Glenn Davidson wrote: > Hi, > > I was looking on the RXTX site for information on the existence of > a 64 bit version of the RXTX windows library. I don't believe it currently > exists as a binary download. Is this correct? > > What would be involved in compiling the source code to create one? > Hi Glenn, The rxtx code for w32 has not been proven on w64 as far as I know. It shouldn't be far off. Win32 code is completely removed from Java. The code in question is limited to termios.c. Everything else works in a 64 bit environment as far as I know. Linux and Solaris work. Windows is treated as a Unix like OS via termios.c. I have no suggestions for how to build it at this time. My history on the subject involved seeing gcc did not support it when I had spare cycles. Now I see gcc probably does support the builds. You also have the Microsoft toolchain available. w32 builds are not end user or windows developer friendly. I did not have access to windows tools when rxtx was developed. Someplace in my mailbox I have an update for the windows based builds. I can't find it ATM. Thats not unusual. There are many thousands of emails going into there. Perhaps someone would be willing to post an updated Makefile for w32 build on windows. There is also an effort to upgrade mingw build files. These communications should stay on the mail-list (trust me). It takes significant effort for me to just keep up with the mail-list. When I'm required to do something, it's 50/50 that it may get dropped when I put on a firehat and run off to something else. Dropped threads are not intentional. It's a bandwidth problem. That's how things are but I would not get depressed. There are enough interested people on the list that it should be possible to get it working. For many it is a new direction learning to trust that people with common interests will get something done. The Mac users have even less support and are doing well. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Mon Jan 21 19:56:31 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Mon, 21 Jan 2008 21:56:31 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: <47955B5F.8060501@gmail.com> All, Here is a makefile which I generated that works on my Windows XP machine. I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I rearranged the files somewhat as described below. Open issues: 1) I don't think that serial.def is still needed - remove if confirmed 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - need to find out what this means. Hope this helps. Beat # # This makefile has been tested in an Eclipse 3.3/CDT environment with MinGW 5.1.3 # # The following file structure is expected: # src/gnu/io --- for all java source files # bin/ --- for compiled java classes # jnibin/ --- for compiled c/c++ files as well as RXTXcom.jar and serial.dll # jniinc/ --- for autogenerate include files # ./ --- for all c/c++/h files and this makefile # # 1/2008, Beat J. Arnet # # Path to MinGW binaries MINGW_BIN_PATH=C:\MinGW\bin # Path to JDK JDK_PATH=C:\Program Files\Java\jdk1.5.0_13 # No need to modify below CLASS_PATH=bin JNI_INC=jniinc JNI_BIN=jnibin CC=$(MINGW_BIN_PATH)\gcc CFLAGS=-I"$(JDK_PATH)\include" -I"$(JDK_PATH)\include\win32" -I$(JNI_INC) -I. -Wall -D_JNI_IMPLEMENTATION_ -O2 -DWIN32 -D __int64="long long" DLLFLAGS= -shared -Wl,--kill-at # discontinued options: -mno-cygwin, -mno-fp-ret-in-387 # todo: retire Serial.def (if confirmed) OBJS=$(JNI_BIN)/init.o $(JNI_BIN)/SerialImp.o $(JNI_BIN)/termios.o $(JNI_BIN)/fuserImp.o $(JNI_BIN)/fixup.o JNICLASSES=gnu.io.CommPortIdentifier gnu.io.RXTXCommDriver gnu.io.RXTXPort all : $(JNI_BIN)\rxtxSerial.dll $(JNI_BIN)\rxtxSerial.dll : $(OBJS) Serial.def $(MINGW_BIN_PATH)\gcc $(DLLFLAGS) -o $(JNI_BIN)\rxtxSerial.dll $(OBJS) Serial.def $(JNI_BIN)/%.o: %.c $(JNI_BIN)\RXTXcomm.jar $(JNI_INC)\config.h $(CC) $(CFLAGS) -c $< -o $@ $(JNI_INC)\config.h: echo #define HAVE_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SIGNAL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FCNTL_H 1 >> $(JNI_INC)\config.h echo #define HAVE_SYS_FILE_H 1 >> $(JNI_INC)\config.h echo #undef HAVE_SYS_SIGNAL_H" >> $(JNI_INC)\config.h echo #undef HAVE_TERMIOS_H >> $(JNI_INC)\config.h $(JNI_BIN)\RXTXcomm.jar: $(JDK_PATH)\bin\javac -d bin -O src/gnu/io/*.java $(JDK_PATH)\bin\jar -cf $(JNI_BIN)\RXTXcomm.jar -C bin . $(JDK_PATH)\bin\javah -jni -d $(JNI_INC) -classpath $(CLASS_PATH) $(JNICLASSES) clean: del $(JNI_BIN)\*.o del $(JNI_BIN)\*.jar del $(JNI_BIN)\*.dll del $(JNI_INC)\*.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080121/81da4657/attachment-0007.html From tjarvi at qbang.org Mon Jan 21 20:08:07 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 21 Jan 2008 20:08:07 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: On Mon, 21 Jan 2008, Beat Arnet wrote: > All, > > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. > > Open issues: > 1) I don't think that serial.def is still needed - remove if confirmed Confirmed. There was a time when we had to generate the exports that would be passed to a linker in order to make a shared library. That's not the case today. (remember some of rxtx code goes back to jdk 1.02 or ~1997). > 2) The dll works, but I get a "Experimental: JNI_OnLoad called." message - Thats dead code talking. It should be gone in the next release. -- Trent Jarvi tjarvi at qbang.org From michael.erskine at ketech.com Tue Jan 22 04:47:18 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 22 Jan 2008 11:47:18 +0000 Subject: [Rxtx] Compiling in Windows In-Reply-To: <47955B5F.8060501@gmail.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> <47955B5F.8060501@gmail.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCE959@no-sv-03.ketech.local> Beat Arnet wrote: > Here is a makefile which I generated that works on my Windows XP machine. > I tested it with MinGW 5.1.3 and the 2.1.7 source files. Note that I > rearranged the files somewhat as described below. Ah! Just what I'm looking for... > # This makefile has been tested in an Eclipse 3.3/CDT environment with > MinGW 5.1.3 ...and I've wanted to have a proper go with CDT under Eclipse on Windows for some time. What we should do here is get together a good free toolchain for developers stuck on Windows. Regards, Michael Erskine. From ajmas at sympatico.ca Tue Jan 22 07:16:10 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 09:16:10 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: On 20-Jan-08, at 07:53 , Dr. Douglas Lyon wrote: > > Configuration appears to be where we are spending most of our time, > in the maintenance cycle. There has got to be a better way. Maven? > Ant? Suggestions? I was thinking about this, and while Maven and Ant are great tools, they only solve the Java side of things. The building of RXTX for the most part involves native code and this is where tools such as Make and Configure have their strengths. They may not necessarily be the greatest things since slide bread, but trying to deal with differences in architectures and assumptions of different platforms is quite an arduous ordeal. If there are better tools to dealing with the building of native code on different platforms, then I am not aware of them. It should be noted that I have once made a native build file with Ant, but it depended on non-standard tasks, meaning something else to install, and it wouldn't have dealt well with trying to work out the specifics on each individual platform. Andre From james.i.brannan at lmco.com Tue Jan 22 08:19:32 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 10:19:32 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Regarding the not reproducable...is it possible then the problem might lie with the RTS? Remember, what's happening is that the RTS is powering the CTS. It doesn't seem likely, though, as all the sensors are doing is opening/closing the flow between RTS and CTS. I will try this on another pc and see if I get the same behavior. From james.i.brannan at lmco.com Tue Jan 22 09:32:40 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Tue, 22 Jan 2008 11:32:40 -0500 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: Sorry about the code...I a little bit of unused code from it to make it shorter. Remember, I experienced the same results using RXTX without the dongle. Errr....oops, I just realized something though, we are *NOT* doing the same test. Seems I forgot to unattach the DSR sensor....so in fact the RXTX code is getting both CTS and DSR signals (I'm just not handling it in my listener)....sorry about that detail. I will have to test again tonight one with both sensors, one with only CTS. -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, January 22, 2008 11:27 AM To: Brannan, James I (N-Fenestra) Cc: tjarvi at qbang.org Subject: RE: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm I really doubt it. Microsoft and Sun did _not_ get along back then. Remember the antitrust case. Microsoft would not share undocumented APIs. The serial API is fairly close to being 'on the hardware' as it is. There would not be much underneath. I have two and a half suspicions. The first is that for some reason the voltage was not enough to trigger cts consistantly. The second is you used a USB dongle with rxtx and it's kernel driver isn't doing what is expected. The half suspicion is your code did not compile. Are you sure we are trying the exact same test? I had to add the port enumeration to get CommPortIdentifier. The test of cts was unchanged. Perhaps you are doing something with a GUI and by chance, rxtx is being impacted. btw, I was just triggering from a live wire from the serial port too. The only difference is I used only a wire between the pins (in a breakout box). Why don't you mail me the dll you used just so I can verify that it wasnt something different in the native code. I doubt it but we can try. On Tue, 22 Jan 2008, Brannan, James I (N-Fenestra) wrote: > Dumb question...is it possible that Sun is accessing the underlying port > bypassing the layer RXTX uses? > > -----Original Message----- > From: Brannan, James I (N-Fenestra) > Sent: Tuesday, January 22, 2008 10:20 AM > To: 'rxtx at qbang.org' > Cc: 'tjarvi at qbang.org' > Subject: Re: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm > > Regarding the not reproducable...is it possible then the problem might > lie with the RTS? Remember, what's happening is that the RTS is > powering the CTS. It doesn't seem likely, though, as all the sensors > are doing is opening/closing the flow between RTS and CTS. I will try > this on another pc and see if I get the same behavior. > From Bob_Jacobsen at lbl.gov Tue Jan 22 09:54:22 2008 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 22 Jan 2008 08:54:22 -0800 Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: References: Message-ID: At 10:19 AM -0500 1/22/08, Brannan, James I (N-Fenestra) wrote: >Regarding the not reproducable...is it possible then the problem might >lie with the RTS? Remember, what's happening is that the RTS is >powering the CTS. It doesn't seem likely, though, as all the sensors >are doing is opening/closing the flow between RTS and CTS. I will try >this on another pc and see if I get the same behavior. Make sure that you have all the flow control options explicitly disabled in your code, so that there's no "automagic" attempts to change the various control leads. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From bschlining at gmail.com Tue Jan 22 10:25:33 2008 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 22 Jan 2008 09:25:33 -0800 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. Anyone on the list ever use autoconf and automake? > It should be noted that I have once made a native build file with Ant, > but it depended on non-standard tasks, meaning something else to > install, > and it wouldn't have dealt well with trying to work out the specifics > on each individual platform. Ant can bootstrap non-standard tasks (i.e. fetch and run) without requiring the user to install them. I'm not suggesting that Ant is an appropriate way to build the native code, just that there's ways to do it without forcing the user to install ant extensions manually. Here's a snippet for bootstrapping the maven-artifact-ant plugin in a build.xml file: ... -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080122/fe76b6ba/attachment-0006.html From ajmas at sympatico.ca Tue Jan 22 18:23:26 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 22 Jan 2008 20:23:26 -0500 Subject: [Rxtx] macos compilation In-Reply-To: References: Message-ID: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > Configuration appears to be where we are spending most of our time, > > in the maintenance cycle. There has got to be a better way. Maven? > > Ant? Suggestions? > > If there are better tools to dealing with the building of native code > on different platforms, then I am not aware of them. > > Anyone on the list ever use autoconf and automake? We already use autoconf. The configure script is the result of running autoconf, taking configure.in as input. Andre From jamesbrannan at earthlink.net Tue Jan 22 20:46:47 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Tue, 22 Jan 2008 22:46:47 -0500 (GMT-05:00) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm Message-ID: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> I did notice in your printout some inconsistencies in the readings, albeit not nearly what I experienced. Were you able to keep the rate of events constant? I was able to keep them very constant this time when I tested. Duplicated the test today. This time I removed the cadence magnet so that DSR event was never raised (circuit was never closed for DSR). I also didnt use a dongle. Only CTS events would be raised this time. Same results, RXTX would not consistently raise CTS events on my Windows XP, the Sun Comm API would. Also, I redid the Linux test, same results,RXTX performed remarkably. So, I'm trying to think what the next step would be. I suppose I should try it using another PC, however, it seems to me that if it was my operating system/computer setup Sun's would have a problem too. I'm thinking/hoping as OS X is really BSD, that it should work on OS X, though I wont know until this weekend. What would you suggest as the next step I should take? Results follow, same code as before. The difference is striking. When I watch the RXTX on windows, its as if Windows just isnt registering events at all for a second, then suddenly deciding to register events for a second or so, not register events, register events...like something is blocking or hanging. My next step is to figure out how to build the windows dll, and add in some debugging code to it, unless you think that's not worthwhile at this point. RXTX Windows: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201055567796E12Speed: 6.273481595715637E-9 cts change: 9688.0Speed: 0.7777456647398844 cts change: 312.0Speed: 24.150000000000002 cts change: 2657.0Speed: 2.8358298833270608 cts change: 640.0Speed: 11.773125 cts change: 2110.0Speed: 3.570995260663507 cts change: 312.0Speed: 24.150000000000002 cts change: 3360.0Speed: 2.2425 cts change: 5546.0Speed: 1.3586007933645872 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 5860.0Speed: 1.28580204778157 cts change: 937.0Speed: 8.041408751334044 cts change: 625.0Speed: 12.05568 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 625.0Speed: 12.05568 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 313.0Speed: 24.072843450479233 cts change: 937.0Speed: 8.041408751334044 cts change: 938.0Speed: 8.032835820895523 cts change: 1250.0Speed: 6.02784 cts change: 17265.0Speed: 0.4364205039096438 cts change: 3125.0Speed: 2.411136 cts change: 2500.0Speed: 3.01392 cts change: 313.0Speed: 24.072843450479233 cts change: 312.0Speed: 24.150000000000002 cts change: 625.0Speed: 12.05568 cts change: 7032.0Speed: 1.0715017064846417 cts change: 625.0Speed: 12.05568 cts change: 8593.0Speed: 0.8768532526475038 cts change: 2907.0Speed: 2.5919504643962847 cts change: 1953.0Speed: 3.8580645161290326 cts change: 2578.0Speed: 2.9227307990690456 cts change: 3203.0Speed: 2.352419606618795 cts change: 2891.0Speed: 2.6062953995157385 cts change: 312.0Speed: 24.150000000000002 cts change: 5078.0Speed: 1.4838125246159906 cts change: 3516.0Speed: 2.1430034129692834 cts change: 2891.0Speed: 2.6062953995157385 cts change: 3515.0Speed: 2.1436130867709817 cts change: 313.0Speed: 24.072843450479233 cts change: 2265.0Speed: 3.3266225165562915 cts change: 313.0Speed: 24.072843450479233 cts change: 2578.0Speed: 2.9227307990690456 Sun's Comm DLL Windows ============================================================= cts change: 1.201055798875E12Speed: 6.27348038871938E-9 cts change: 421.0Speed: 17.897387173396677 cts change: 344.0Speed: 21.903488372093022 cts change: 328.0Speed: 22.971951219512196 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 265.0Speed: 28.43320754716981 cts change: 266.0Speed: 28.326315789473686 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 266.0Speed: 28.326315789473686 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 297.0Speed: 25.36969696969697 cts change: 282.0Speed: 26.719148936170214 cts change: 296.0Speed: 25.455405405405408 cts change: 282.0Speed: 26.719148936170214 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 328.0Speed: 22.971951219512196 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 cts change: 297.0Speed: 25.36969696969697 cts change: 297.0Speed: 25.36969696969697 cts change: 281.0Speed: 26.81423487544484 cts change: 313.0Speed: 24.072843450479233 cts change: 281.0Speed: 26.81423487544484 RXTX Linux: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 cts change: 1.201052778098E12Speed: 6.2734961671977396E-9 cts change: 408.0Speed: 18.46764705882353 cts change: 372.0Speed: 20.25483870967742 cts change: 332.0Speed: 22.695180722891568 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 296.0Speed: 25.455405405405408 cts change: 292.0Speed: 25.804109589041097 cts change: 304.0Speed: 24.785526315789475 cts change: 292.0Speed: 25.804109589041097 cts change: 300.0Speed: 25.116 cts change: 304.0Speed: 24.785526315789475 cts change: 304.0Speed: 24.785526315789475 cts change: 316.0Speed: 23.844303797468356 cts change: 296.0Speed: 25.455405405405408 cts change: 304.0Speed: 24.785526315789475 cts change: 308.0Speed: 24.463636363636365 cts change: 300.0Speed: 25.116 cts change: 316.0Speed: 23.844303797468356 cts change: 305.0Speed: 24.704262295081968 cts change: 307.0Speed: 24.543322475570033 cts change: 312.0Speed: 24.150000000000002 cts change: 300.0Speed: 25.116 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 328.0Speed: 22.971951219512196 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 315.0Speed: 23.92 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 304.0Speed: 24.785526315789475 cts change: 313.0Speed: 24.072843450479233 cts change: 319.0Speed: 23.620062695924766 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 324.0Speed: 23.255555555555556 cts change: 313.0Speed: 24.072843450479233 cts change: 323.0Speed: 23.327554179566565 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 328.0Speed: 22.971951219512196 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 328.0Speed: 22.971951219512196 cts change: 312.0Speed: 24.150000000000002 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 308.0Speed: 24.463636363636365 cts change: 308.0Speed: 24.463636363636365 cts change: 313.0Speed: 24.072843450479233 cts change: 303.0Speed: 24.867326732673266 cts change: 312.0Speed: 24.150000000000002 cts change: 308.0Speed: 24.463636363636365 cts change: 316.0Speed: 23.844303797468356 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 321.0Speed: 23.472897196261684 cts change: 315.0Speed: 23.92 cts change: 320.0Speed: 23.54625 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 312.0Speed: 24.150000000000002 cts change: 320.0Speed: 23.54625 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 308.0Speed: 24.463636363636365 cts change: 320.0Speed: 23.54625 cts change: 313.0Speed: 24.072843450479233 cts change: 311.0Speed: 24.227652733118973 cts change: 324.0Speed: 23.255555555555556 cts change: 312.0Speed: 24.150000000000002 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 316.0Speed: 23.844303797468356 cts change: 324.0Speed: 23.255555555555556 cts change: 316.0Speed: 23.844303797468356 cts change: 304.0Speed: 24.785526315789475 From tjarvi at qbang.org Tue Jan 22 21:01:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Jan 2008 21:01:25 -0700 (MST) Subject: [Rxtx] RXTX Vs. Java Sun Windows Javax.comm In-Reply-To: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <19683586.1201060007304.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Message-ID: On Tue, 22 Jan 2008, James Brannan wrote: > I did notice in your printout some inconsistencies in the readings, albeit > not nearly what I experienced. Were you able to keep the rate of events > constant? I was not able to keep a constant rate as the timing showed. But as I watched the printout, nothing unexpected was observed. I'll need to build a opamp circuit on a breadboard to be more consistant. I've asked a few questions that I'll repeat now. 1) Is there more code than you posted in your tests? The code you posted does not even compile. 2) Are you using an onboard UART or a USB dongle? 3) could you provide a link to the exact rxtx library you are using? What I see is sane behavior that does not agree with your observations which amount to ~5 or more missed events. I certainly would see that while playing 'morse code' on a breakout box. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Thu Jan 24 11:35:02 2008 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 24 Jan 2008 11:35:02 -0700 Subject: [Rxtx] macos compilation In-Reply-To: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> References: <13B830E1-9C13-4B97-ACDD-633F9A17E2BE@sympatico.ca> Message-ID: <2251ead40801241035k13765fedk8f523695be2b1122@mail.gmail.com> On 1/22/08, Andre-John Mas wrote: > > On 22-Jan-08, at 12:25 , Brian Schlining wrote: > > > > > > > > Configuration appears to be where we are spending most of our time, > > > in the maintenance cycle. There has got to be a better way. Maven? > > > Ant? Suggestions? > > > > If there are better tools to dealing with the building of native code > > on different platforms, then I am not aware of them. > > > > Anyone on the list ever use autoconf and automake? > > We already use autoconf. The configure script is the result of running > autoconf, taking configure.in as input. I've been following the fight for "better autoconf/automake" since about 1997 - it starts to remind an old joke of IT managers of the day (1960s to 1990s) "choosing ${other-os} over Unix" with the punchline being "what part of the message you don't understand?" > Andre --vt From slacorte at ozengineering.com Thu Jan 24 18:05:22 2008 From: slacorte at ozengineering.com (Steven La Corte) Date: Thu, 24 Jan 2008 17:05:22 -0800 (PST) Subject: [Rxtx] rxtx solaris 2.9 SIGSEGV Message-ID: <448113.19444.qm@web412.biz.mail.mud.yahoo.com> We are using rxtx 2.1.7 in a Tomcat 5.5.7 servlet, that is running in Solaris 9 (SunOS 2.9). Our servlet opens 10 threads, and when a request is received, it opens a port, a readThr and writes and receives data from/to a serial port on a digi port server. The readThr is closed when processing is completed, and the port is closed. The servlet receives a request from a client every minute. The client is a cron tab application. The native code for the solaris was downloaded from the rxtx site and labelled for 32bit solaris 2.8. No changes or patches have been applied to the downloaded files (jar or .so). The servlet starts up, opens ports and successfully reads, writes and closes the port to the digi port server (and field devices connected to the digig port server) for a period of time (about one hour). Then we will notice that read attempts begin to not complete and appear to throw interrupt exceptions. Closing and reopening the port doesn't help, no data is still received. And finally, after some time, Tomcat will crash due to a SIGSEGV. I am attaching two typical HotSpot dumps. Any info that can be shared with us will be greatly appreciated. Thanks, Steve La Corte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1559.log Type: application/octet-stream Size: 8899 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0008.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid9786.log Type: application/octet-stream Size: 9310 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080124/f6ba3c0a/attachment-0009.obj From rspencer at FuelQuest.com Fri Jan 25 08:19:16 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Fri, 25 Jan 2008 09:19:16 -0600 Subject: [Rxtx] RXTX 2.1-7 [latest]: getting "Bad file descriptor in nativeavailable" exception Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702FA736E@fqmx03.fuelquest.com> Hello, I am getting several exceptions while using RXTX 2.1-7 [commapi branch latest]. I am running RXTX under Linux version 2.6.9-42.ELsmp (bhcompile at hs20-bc1-1.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Wed Jul 12 23:27:17 EDT 2006 I am catching the following exception: 2008-01-25 00:02:57 ERROR There was an issue trying to read from the port's [/dev/ttyS6] InputStream! java.io.IOException: Bad file descriptor in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1488) at com.testing.readInputStream(ModemTalker.java:926) Also, I'm getting (sent to STDOUT - they may or may not be related) RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS4: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS5: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS4: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS3: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyS1: File exists Here is the method that checks the stream's availablity from the port and read it ... private synchronized void readInputStream() { int x = 0; try { while (isReadyOrConnected() && (getInputStream().available() > 0) && ((x = getInputStream().read()) != -1)) { setReading(true); getOutputBuffer().append((char) x); } setReading(false); } catch (IOException e) { setReading(false); log.error("There was an issue trying to read from the port's [" + getPortName() + "] InputStream!", e); return; } } Does anyone have any ideas for fixes / workarounds? I've checked and my code close all streams and ports after every use so I don't think the lock errors could be because of it (as a secondary check I have my code make sure it is not owned). Since my code retries it seems to work after that, however I would like my code to be exceptional (exception-less). :-) Please provide assistance if you know what's up with it. Thanks. Rodney Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080125/323fc1e3/attachment-0003.html From james.i.brannan at lmco.com Fri Jan 25 15:39:03 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Fri, 25 Jan 2008 17:39:03 -0500 Subject: [Rxtx] Sun vs. Rxtx and now MAC question Message-ID: Apparently my last email never made it to the list. To answer Trent's questions regarding my tests.... 1) I did duplicate the results using a UART and not dongle two days ago. 2) I promise that's the logic in the event handler and the main method was the only part of code running, nothing else going on 3) I reran without the cadence magnet (no DSR) - only one signal coming to RXTX - and got the same strange results But, I replaced my company Dell laptop for a Mac. Now I have a whole new issue....I read the threads on 2.1.8 etc. Being lazy for now, if I do the following below is that sufficient to run 2.1.7 on my Mac (I got the f.a.q. lock problem)... sudo mkdir /var/lock and sudo chmod 1777 /var/lock After testing on Mac I'll go back to trying to figure out windoz.....I'm installing a dual-boot on my Mac (Steve Jobs please forgive me)...so I'll be able to test XP more. James A. Brannan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080125/8d9de59f/attachment-0003.html From zamek at vili.pmmf.hu Sun Jan 27 12:46:22 2008 From: zamek at vili.pmmf.hu (zamek) Date: Sun, 27 Jan 2008 20:46:22 +0100 Subject: [Rxtx] receive timeout depends from data length Message-ID: <200801272046.22281.zamek@vili.pmmf.hu> Hi All, I use rxtx in Debian unstable (ver 2.1.7-r2-3) and Sun Java jdk 6-00-2 (both of them from Debian repository). When I use 8 bits data length and I send something into the port, and there is no response, it returns after 500 ms timeout. When I change data bits to 7 bits, it cannot returns, and wait forever :( Anyone has an idea for workaround it? Flow controls are switched off. I need 7 bits, because it is a plc:( -- ?thx, ?---------------------------------- ?Zoltan Zidarics programmer ?PTE-PMMFK H-7621 Pecs, Boszorkany u. 2. Hungary ?E-Mail: zamek at vili.pmmf.hu ?---------------------------------- From netbeans at gatworks.com Sun Jan 27 17:10:02 2008 From: netbeans at gatworks.com (U George) Date: Sun, 27 Jan 2008 19:10:02 -0500 Subject: [Rxtx] receive timeout depends from data length In-Reply-To: <200801272046.22281.zamek@vili.pmmf.hu> References: <200801272046.22281.zamek@vili.pmmf.hu> Message-ID: <479D1D5A.9070200@gatworks.com> Seems rather silly. what is your issue? is it that u dont get the timeout? or you dont get a response to the byte you sent? Anyway: generally many uarts send/receive an 8bit byte as a rule. Generally when u send an 8bit byte, thats considered to be a raw byte ( ie a byte that does not have a parity bit, mark, or space bit ) , and the uart will not generate an error. when u say 7 bit, there is usually a specification that a parity bit ( even/odd/mark/space) is to be generated for those 7 bits, and inserted into the 8th bit. Well, if you dont generate the correct parity for the receiver of the data, then your byte may just be ignored. Hence no reply from the receiver. I suspect your timeout failure should not have happened. zamek wrote: > Hi All, > > I use rxtx in Debian unstable (ver 2.1.7-r2-3) and Sun Java jdk 6-00-2 (both > of them from Debian repository). > > When I use 8 bits data length and I send something into the port, and there is > no response, it returns after 500 ms timeout. > When I change data bits to 7 bits, it cannot returns, and wait forever :( > > Anyone has an idea for workaround it? > Flow controls are switched off. > I need 7 bits, because it is a plc:( > > -- > thx, > ---------------------------------- > Zoltan Zidarics programmer > PTE-PMMFK H-7621 Pecs, Boszorkany u. 2. Hungary > E-Mail: zamek at vili.pmmf.hu > ---------------------------------- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From jredman at ergotech.com Sun Jan 27 18:09:41 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 27 Jan 2008 18:09:41 -0700 Subject: [Rxtx] receive timeout depends from data length In-Reply-To: <479D1D5A.9070200@gatworks.com> References: <200801272046.22281.zamek@vili.pmmf.hu> <479D1D5A.9070200@gatworks.com> Message-ID: <479D2B55.20107@ergotech.com> Some of the PLC protocols are odd. There're a couple that use 8,O,1, so a 9-bit word. (As I recall that works fine with RXTX). If the PLC is a Modbus PLC, take a look at the SourceForge jamod project - http://sourceforge.net/projects/jamod/. As I recall, they have Modbus RTU support using javacomm (so should work with RXTX). Jim U George wrote: > Seems rather silly. > what is your issue? is it that u dont get the timeout? or you dont get a > response to the byte you sent? > > Anyway: > generally many uarts send/receive an 8bit byte as a rule. Generally when > u send an 8bit byte, thats considered to be a raw byte ( ie a byte that > does not have a parity bit, mark, or space bit ) , and the uart will > not generate an error. > when u say 7 bit, there is usually a specification that a parity bit ( > even/odd/mark/space) is to be generated for those 7 bits, and inserted > into the 8th bit. > Well, if you dont generate the correct parity for the receiver of the > data, then your byte may just be ignored. Hence no reply from the receiver. > > I suspect your timeout failure should not have happened. > > zamek wrote: >> Hi All, >> >> I use rxtx in Debian unstable (ver 2.1.7-r2-3) and Sun Java jdk 6-00-2 (both >> of them from Debian repository). >> >> When I use 8 bits data length and I send something into the port, and there is >> no response, it returns after 500 ms timeout. >> When I change data bits to 7 bits, it cannot returns, and wait forever :( >> >> Anyone has an idea for workaround it? >> Flow controls are switched off. >> I need 7 bits, because it is a plc:( >> >> -- >> thx, >> ---------------------------------- >> Zoltan Zidarics programmer >> PTE-PMMFK H-7621 Pecs, Boszorkany u. 2. Hungary >> E-Mail: zamek at vili.pmmf.hu >> ---------------------------------- >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From rxtx at qbang.org Mon Jan 28 00:35:56 2008 From: rxtx at qbang.org (rxtx at qbang.org) Date: Mon, 28 Jan 2008 00:35:56 -0700 Subject: [Rxtx] January 75% OFF Message-ID: <20080128113550.5151.qmail@dsl.static812141539.ttnet.net.tr> An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080128/06f6af55/attachment.html From zamek at vili.pmmf.hu Mon Jan 28 01:47:11 2008 From: zamek at vili.pmmf.hu (zamek) Date: Mon, 28 Jan 2008 09:47:11 +0100 Subject: [Rxtx] receive timeout depends from data length In-Reply-To: <479D2B55.20107@ergotech.com> References: <200801272046.22281.zamek@vili.pmmf.hu> <479D1D5A.9070200@gatworks.com> <479D2B55.20107@ergotech.com> Message-ID: <200801280947.11883.zamek@vili.pmmf.hu> Hi, Ezzel a d?tummal: Monday 28 January 2008 02.09.41 ezt ?rta: > Some of the PLC protocols are odd. There're a couple that use 8,O,1, so > a 9-bit word. (As I recall that works fine with RXTX). Ok, I know it, but I have to communicate a low cost delta dvp 14ss plc, which works _only_ 9600,8e1 ascii mode :( > If the PLC is a Modbus PLC, take a look at the SourceForge jamod project > - http://sourceforge.net/projects/jamod/. As I recall, they have Modbus > RTU support using javacomm (so should work with RXTX). Yes I use excellent jamod since 2005, and I made a lot of plc projects with it. > U George wrote: > > Seems rather silly. > > what is your issue? is it that u dont get the timeout? or you dont get a > > response to the byte you sent? With jamod I send a request, which is sent well onto the line, and waits to response. If plc is offline, it doesn't response and the wait never ends. The timeout setting is 500ms. When I set to 8 bits data length, it returns and reports no response, but if I change _only_ the data length from 8 bits to 7 bits, it waits forever. > > Anyway: > > generally many uarts send/receive an 8bit byte as a rule. Generally when > > u send an 8bit byte, thats considered to be a raw byte ( ie a byte that > > does not have a parity bit, mark, or space bit ) , and the uart will > > not generate an error. > > when u say 7 bit, there is usually a specification that a parity bit ( > > even/odd/mark/space) is to be generated for those 7 bits, and inserted > > into the 8th bit. > > Well, if you dont generate the correct parity for the receiver of the > > data, then your byte may just be ignored. Hence no reply from the > > receiver. Yes, its true, but if there is no plc (line is empty), I expect to returns and reports no received bytes after the timeout. -- ?thx, ?---------------------------------- ?Zoltan Zidarics programmer ?PTE-PMMFK H-7621 Pecs, Boszorkany u. 2. Hungary ?E-Mail: zamek at vili.pmmf.hu ?---------------------------------- From lyon at docjava.com Wed Jan 2 07:09:47 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 02 Jan 2008 09:09:47 -0500 Subject: [Rxtx] serial port reliability on the Intel Mac Message-ID: Hi All, I am trying to dial the phone with an external modem, and a Keyspan 19HS USB-RS232 adapter. All this, running on an Intel Mac (10.4). When I first start my program, sometimes the serial port works, right away. Other times, it just sits there and does not work at all. I compiled with NO LOCKS on in configure...but this used to work OK. I am using RTS/CTS for the handshake. When it works, it works well. I have recompiled the RXTX library with the DEBUG on. Because the bug is intermittent, this is not easy to debug. An interesting error: The file: gnu.io.rxtx.properties doesn't exists. java.io.FileNotFoundException: /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties (No such file or directory) checking for system-known ports of type 2 checking registry for ports of type 2 Should I check for the existence of the properties file and create it if it does not exist? Would this ease the serial port discovery process? And can this file be created in a cross-platform way? I seem to recall that discovering serial ports on various systems is a hard problem, perhaps because there are no standard naming conventions. My serial port has the user-fiendly name: cu.USA19Hfd13P1.1 And the process of discovery is very noisy.... ... checking for system-known ports of type 1 checking registry for ports of type 1 CommPortIdentifier:addPortName(/dev/tty.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(/dev/cu.KeySerial1) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) ... Which means, I think, that it is finding stuff. It then goes and lists everything in /dev (a list to long to reproduce here without irritating people). The process of discovery culminates with: valid port prefixes: Leaving registerValidPorts() /dev/tty.KeySerial1 /dev/cu.KeySerial1 /dev/tty.USA19Hfd13P1.1 /dev/cu.USA19Hfd13P1.1 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem The Discovery process is being executed EVERY TIME I use the serial port. This is almost certainly because I am doing something terribly wrong...what, I don't know. I suspect the properties file is at issue, here. I am the only one using my computer and there are no other programs using the serial port, as far as I know. Any ideas? Thanks! - Doug From tjarvi at qbang.org Wed Jan 2 17:29:24 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 17:29:24 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: On Mon, 10 Dec 2007, Daniel Wippermann wrote: > Hi everone, > >> Hi all, >>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>> progress. it does not lockout the other from happening simultaneously. >>> The synchronize read() does prevent simultaneous reads from multiple >>> threads. >>> The IOLocked indicator does prevent the close() from starting up, as >>> close() waits for the IOLock value to become 0. The presumption is that >>> the application's reads/writes will cease because the application has >>> issued a close(). You wouldnt issue any further I/O after the close - >>> would you? >> You are completely right, I never meant to imply something different. The >> IOLocked shall not lock concurrent reads or concurrents writes away, but be >> a signal for the close method that some read or write is still underway and >> it has to wait for them to finish. >> But the original question was, why the IOLocked variable has a value != 0 >> ALTHOUGH all read and write activities have ceased quite a while ago? And >> there were only two threads involved: on one side the thread that called >> open() and write() and on the other side the RXTX monitor thread that >> calling read(). No multiple reads or writes! Only a parallel write while >> reading. But that cannot be forbidden since we talk about an USART. Or am I >> wrong? Is there a problem to to have one read() and one write() run >> simulatenously? >> If that case is an allowed one, IOLocked has to be synchronized because it >> is altered in read() and write(). > I've prepared a patch to RXTXPort.java to help me outline my point of view in > this discussion. It's attached to this posting. > > In general, three things have been done: > > 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be > passed as a parameter to the synchronized statement. > > 2) Every "IOLocked++" is encapsulated by that said synchronized block > > 3) In some methods there were multiple "IOLocked--". Those have all been > substituted by a one synchronized "IOLocked--" which is processed in a > "finally" statement that handles all exceptions from right after "IOLocked++" > till the end of the method. > > So every occurence or variation of the sequence: > >> IOLocked++; >> waitForTheNativeCodeSilly(); >> try { >> // something method specific here >> } catch (IOException ex) { >> IOLocked--; >> throw ex; >> } >> IOLocked--; > > has been replaced by: > >> synchronized (IOLockedMutex) { >> IOLocked++; >> } >> try { >> waitForTheNativeCodeSilly(); >> // something method specific here >> } finally { >> synchronized (IOLockedMutex) { >> IOLocked--; >> } >> } > > In my opinion that chance has no impact on the surrounding application. It > wont block away one function call if another one is running, it only ensures, > that only one thread alters the IOLocked variable at any given time. So you > could have one polling read() and one write() action in parallel without > interference. > > In the hope, that I haven't abused your patience too much :) > Daniel > > Thanks Daniel, I'm trying the patch now with a testcase. Assuming it spins overnight without issue, it looks like a winner. Revisiting Uncle Georges suggestion of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive but adds yet another obstical for people using older (1.4) JREs. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jan 2 18:02:38 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 18:02:38 -0700 (MST) Subject: [Rxtx] serial port reliability on the Intel Mac In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I am trying to dial the phone with an external modem, > and a Keyspan 19HS USB-RS232 adapter. > > All this, running on an Intel Mac (10.4). When I first > start my program, sometimes the serial port works, right away. > Other times, it just sits there and does not work at all. > > I compiled with NO LOCKS on in configure...but this used to work OK. > > I am using RTS/CTS for the handshake. When it works, it works > well. I have recompiled the RXTX library with the DEBUG on. > > Because the bug is intermittent, this is not easy to debug. > > An interesting error: > The file: gnu.io.rxtx.properties doesn't exists. > java.io.FileNotFoundException: > /Users/lyon/Library/Java/Extensions:/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/gnu.io.rxtx.properties > (No such file or directory) > checking for system-known ports of type 2 > checking registry for ports of type 2 > > Should I check for the existence of the properties file and create it > if it does not > exist? Would this ease the serial port discovery process? > > And can this file be created in a cross-platform way? > > I seem to recall that discovering serial ports on various systems is > a hard problem, > perhaps because there are no standard naming conventions. > > My serial port has the user-fiendly name: > cu.USA19Hfd13P1.1 > > And the process of discovery is very noisy.... > ... > checking for system-known ports of type 1 > checking registry for ports of type 1 > CommPortIdentifier:addPortName(/dev/tty.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:AddIdentifierToList() null > CommPortIdentifier:addPortName(/dev/cu.KeySerial1) > CommPortIdentifier:AddIdentifierToList() > CommPortIdentifier:addPortName(/dev/tty.USA19Hfd13P1.1) > ... > Which means, I think, that it is finding stuff. > > It then goes and lists everything in /dev (a list to long to reproduce > here without irritating people). > > The process of discovery culminates with: > valid port prefixes: > Leaving registerValidPorts() > /dev/tty.KeySerial1 > /dev/cu.KeySerial1 > /dev/tty.USA19Hfd13P1.1 > /dev/cu.USA19Hfd13P1.1 > /dev/tty.Bluetooth-PDA-Sync > /dev/cu.Bluetooth-PDA-Sync > /dev/tty.Bluetooth-Modem > /dev/cu.Bluetooth-Modem > > The Discovery process is being executed EVERY TIME I use the serial port. > This is almost certainly because I am doing something terribly > wrong...what, I don't > know. I suspect the properties file is at issue, here. > > I am the only one using my computer and there are no other programs using the > serial port, as far as I know. > > Any ideas? > Hi Doug, Maybe by eliminating the obvious, we can help you get going. The javax.comm.properties file may be used to predefine available ports or map existing ports to other names (handy if you like to use Mac syntax on another platform). It probably has nothing to do with the issue. Mac OS X code locks out other access if the port is open (we don't recommend lockfiles on Mac anymore). You just cant open the port if rxtx has it open. Some of your ports are represented twice. cu vs tty (callout device vs terminal?) It is the same hardware underneath. Perhaps you are creating a new CommDriver when you open your port? We used to cache the info and repeat it but I think we patched it so you can plug in a USB dongle, have the port showup when you try to get the enumaration. at least on Linux 'fuser' will tell you if a device file is in use. >From the list of valid ports listed above, rxtx found it and it should open if all is well in userland. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Wed Jan 2 19:34:58 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Wed, 02 Jan 2008 21:34:58 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477C49D2.5050408@gmail.com> Trent Jarvi wrote: > On Mon, 10 Dec 2007, Daniel Wippermann wrote: > > >> Hi everone, >> >> >>> Hi all, >>> >>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>> progress. it does not lockout the other from happening simultaneously. >>>> The synchronize read() does prevent simultaneous reads from multiple >>>> threads. >>>> The IOLocked indicator does prevent the close() from starting up, as >>>> close() waits for the IOLock value to become 0. The presumption is that >>>> the application's reads/writes will cease because the application has >>>> issued a close(). You wouldnt issue any further I/O after the close - >>>> would you? >>>> >>> You are completely right, I never meant to imply something different. The >>> IOLocked shall not lock concurrent reads or concurrents writes away, but be >>> a signal for the close method that some read or write is still underway and >>> it has to wait for them to finish. >>> But the original question was, why the IOLocked variable has a value != 0 >>> ALTHOUGH all read and write activities have ceased quite a while ago? And >>> there were only two threads involved: on one side the thread that called >>> open() and write() and on the other side the RXTX monitor thread that >>> calling read(). No multiple reads or writes! Only a parallel write while >>> reading. But that cannot be forbidden since we talk about an USART. Or am I >>> wrong? Is there a problem to to have one read() and one write() run >>> simulatenously? >>> If that case is an allowed one, IOLocked has to be synchronized because it >>> is altered in read() and write(). >>> >> I've prepared a patch to RXTXPort.java to help me outline my point of view in >> this discussion. It's attached to this posting. >> >> In general, three things have been done: >> >> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be >> passed as a parameter to the synchronized statement. >> >> 2) Every "IOLocked++" is encapsulated by that said synchronized block >> >> 3) In some methods there were multiple "IOLocked--". Those have all been >> substituted by a one synchronized "IOLocked--" which is processed in a >> "finally" statement that handles all exceptions from right after "IOLocked++" >> till the end of the method. >> >> So every occurence or variation of the sequence: >> >> >>> IOLocked++; >>> waitForTheNativeCodeSilly(); >>> try { >>> // something method specific here >>> } catch (IOException ex) { >>> IOLocked--; >>> throw ex; >>> } >>> IOLocked--; >>> >> has been replaced by: >> >> >>> synchronized (IOLockedMutex) { >>> IOLocked++; >>> } >>> try { >>> waitForTheNativeCodeSilly(); >>> // something method specific here >>> } finally { >>> synchronized (IOLockedMutex) { >>> IOLocked--; >>> } >>> } >>> >> In my opinion that chance has no impact on the surrounding application. It >> wont block away one function call if another one is running, it only ensures, >> that only one thread alters the IOLocked variable at any given time. So you >> could have one polling read() and one write() action in parallel without >> interference. >> >> In the hope, that I haven't abused your patience too much :) >> Daniel >> >> >> > > Thanks Daniel, > > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > All, While the patch proposed by Daniel seems to work fine, it brought the CPU of my computer to a grinding halt (both with synchronized statements and AtomicIntegers). What do you think about George's (?) suggestion of getting rid of IOLocked altogether? Beat Arnet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080102/9a49b727/attachment-0027.html From tjarvi at qbang.org Wed Jan 2 20:55:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 2 Jan 2008 20:55:57 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477C49D2.5050408@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: On Wed, 2 Jan 2008, Beat Arnet wrote: > Trent Jarvi wrote: >> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >> >> >>> Hi everone, >>> >>> >>>> Hi all, >>>> >>>>> The IOLocked is a flag to indicate that a read/write I/O operation is in >>>>> progress. it does not lockout the other from happening simultaneously. >>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>> threads. >>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>> close() waits for the IOLock value to become 0. The presumption is that >>>>> the application's reads/writes will cease because the application has >>>>> issued a close(). You wouldnt issue any further I/O after the close - >>>>> would you? >>>>> >>>> You are completely right, I never meant to imply something different. The >>>> IOLocked shall not lock concurrent reads or concurrents writes away, but >>>> be a signal for the close method that some read or write is still >>>> underway and it has to wait for them to finish. >>>> But the original question was, why the IOLocked variable has a value != >>>> 0 ALTHOUGH all read and write activities have ceased quite a while ago? >>>> And there were only two threads involved: on one side the thread that >>>> called open() and write() and on the other side the RXTX monitor thread >>>> that calling read(). No multiple reads or writes! Only a parallel write >>>> while reading. But that cannot be forbidden since we talk about an USART. >>>> Or am I wrong? Is there a problem to to have one read() and one write() >>>> run simulatenously? >>>> If that case is an allowed one, IOLocked has to be synchronized because >>>> it is altered in read() and write(). >>>> >>> I've prepared a patch to RXTXPort.java to help me outline my point of view >>> in this discussion. It's attached to this posting. >>> >>> In general, three things have been done: >>> >>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to >>> be passed as a parameter to the synchronized statement. >>> >>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>> >>> 3) In some methods there were multiple "IOLocked--". Those have all been >>> substituted by a one synchronized "IOLocked--" which is processed in a >>> "finally" statement that handles all exceptions from right after >>> "IOLocked++" till the end of the method. >>> >>> So every occurence or variation of the sequence: >>> >>> >>>> IOLocked++; >>>> waitForTheNativeCodeSilly(); >>>> try { >>>> // something method specific here >>>> } catch (IOException ex) { >>>> IOLocked--; >>>> throw ex; >>>> } >>>> IOLocked--; >>>> >>> has been replaced by: >>> >>> >>>> synchronized (IOLockedMutex) { >>>> IOLocked++; >>>> } >>>> try { >>>> waitForTheNativeCodeSilly(); >>>> // something method specific here >>>> } finally { >>>> synchronized (IOLockedMutex) { >>>> IOLocked--; >>>> } >>>> } >>>> >>> In my opinion that chance has no impact on the surrounding application. It >>> wont block away one function call if another one is running, it only >>> ensures, that only one thread alters the IOLocked variable at any given >>> time. So you could have one polling read() and one write() action in >>> parallel without interference. >>> >>> In the hope, that I haven't abused your patience too much :) >>> Daniel >>> >>> >>> >> >> Thanks Daniel, >> >> I'm trying the patch now with a testcase. Assuming it spins overnight >> without issue, it looks like a winner. Revisiting Uncle Georges suggestion >> of using java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >> attractive but adds yet another obstical for people using older (1.4) JREs. >> >> > All, > While the patch proposed by Daniel seems to work fine, it brought the CPU of > my computer to a grinding halt (both with synchronized statements and > AtomicIntegers). What do you think about George's (?) suggestion of getting > rid of IOLocked altogether? > > Beat Arnet > > Hi Beat, While I like the idea of close really closing on demand, I'm afraid of the possible places we may 'squirt' all sorts of interesting messages and exceptions into production apps. Those that have seen the code can probably relate to how we learned about the various issues after coding those methods. Close used to do as you would like. I think it is possible to go back to that behavior since identifying other sources of problems. I would not expect the cpu to jump. I'll try to confirm it tomorrow. Which OS are you running on? I'm guessing you are doing frequent, small reads and writes? If George or you would like to prepare a patch to try, we can all spin it and discuss. It is probably not that bad to do. It would be nice to get rid of the extra code in there if we can do it safely. -- Trent Jarvi tjarvi at qbang.org From james.i.brannan at lmco.com Thu Jan 3 12:42:11 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:42:11 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Quick question. Probably dumb, but I have never developed a real-time system before. Not asking about my code, yet, but opinions on if rxtx should be able to handle events occurring this quickly.... I count pulses from CTS and DSR where CTS is speed, and DSR is cadence. I'll spare you the details, but the same wiring for a different project can be viewed here: http://users.pandora.be/jim.de.sitter/html/spinner.html What I do is if event changes state (from true to false) count this as a tick, get the elapsed time, and calculate the speed - about four lines of code altogether. Events occur at a very quick rate, two per rotation of the wheel, two per rotation of the crank. Do you think this is too fast an occurrence of events for rxtx and Java, necessitating going native? What about if I throw this on a older 500mghz computer with 128mg of ram, as I was thinking users of this product would want a dedicated machine in their basement/work-out room, it would be an old pc/mac/linux box relegated to running my software. If you think rxtx should have no problem, then I'll start by optimizing my code into a producer/consumer sort of thing. If that doesn't work, then I'll start posting code and asking specific questions. BTW, I use loadlibrary in my code to load the serialport dll, also, I was lazy and didn't delete the old sun serialport stuff out of the jdk folders, the way I'm loading or the old stuff being in my paths wouldn't have something to do with it, would it? James A. Brannan Impulse Software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/063d1193/attachment-0026.html From james.i.brannan at lmco.com Thu Jan 3 12:51:31 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Thu, 03 Jan 2008 14:51:31 -0500 Subject: [Rxtx] RXTX Realtime Question Message-ID: Just realized I left off the problem/observation in the previous email.... When using the java serial port package for windows I had no problems. When I switched to RXTX it appeared as if it was "loosing" data somehow and the speed and cadence was all over the place.... At this point I'm just trying to see if others with more experience think maybe I'm asking too much of non-compiled code, speed wise..... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/9bf46df7/attachment-0026.html From gergg at cox.net Thu Jan 3 14:18:23 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 15:18:23 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D511F.9080607@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Yes, but it does provide a great reduction in memory synchroization that can horribly reduce the benefits of multi-core machines. It would be good to perhaps provide an alternate class implementation that would be loaded when the VM supports it. Gregg Wonderly From netbeans at gatworks.com Thu Jan 3 14:44:21 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 03 Jan 2008 16:44:21 -0500 Subject: [Rxtx] RXTX Realtime Question In-Reply-To: References: Message-ID: <477D5735.3070204@gatworks.com> Brannan, James I (N-Fenestra) wrote: > Just realized I left off the problem/observation in the previous email?. > real-time implies certain things. There has to be a thread that is running in real-time. This sorta also implies that the device driver also runs in real time ( which they tend to do ) . If you put 1 and 1 together, u really got to have a java thread that is runnable at ( device ) interrupt level. Then you have a real-time java thread. This scenario has not happened, or likely to happen ( as far as I am aware ) . But as far as what you have said, u should be able to run in a (much older ) 486 box . But I dont know how quickly is quickly! But, of what u have said, it also comes to mind that u need to have the signal/event processor at a high thread priority. AND less priority to other threads. This way the serial i/o event driver will get run-time before all the other ( lower priority ) threads. I dont know if this is done in RXTX et al. From gergg at cox.net Thu Jan 3 15:10:22 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:10:22 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D5D4E.4040902@cox.net> Trent Jarvi wrote: > If George or you would like to prepare a patch to try, we can all spin it > and discuss. It is probably not that bad to do. It would be nice to get > rid of the extra code in there if we can do it safely. Attached is a patch which corrects the concurrency issues with RXTXPort.java. I've made some changes which, ultimately may not be needed, but my changes make the class safe for concurrency. The use of volatile is required for any variable which may be read in one thread, unsynchronized, while it is written in another thread. The loop, waiting for IOLocked to be zero would not terminate in the typical case because the compiler would optimize it to if( IOLocked != 0 ) { while( true ) { ... } } because it is not volatile, no synchronized access occurs, and no writes to the value occur within that loop. Please apply this diff and see what happens. I don't have a test environment here, but these change should rectify any concurrency issues with this class. From a simple perspective, every class level variable in a java class should either be declared final or volatile to be concurrency SAFE (as opposed to optimally correct). If you understand the flow of code execution, and can be assured that only a single thread ever accesses a particular class variable (or it is always synchronized on the same object reference) then you can avoid the use of volatile which will cause caching related synchronizations to occur on each reference. The AtomicInteger etc classes are designed to avoid the synchronization that volatile forces by using CAS spins to update values as in while( !CAS( A, A+1 ) ); instead of the concurrency killer synchronized( cache ) { a = a+1; } Multi-core processors have brought about a whole new potential for performance. Unfortunately, software systems like Java don't provide you with "always correct" operation because we still think it's more important to optimize performance over guaranteed correctness. The concurrency-interest mailing list has a wealth of knowledgeable people, including Doug Lea, all who can answer concurrency questions quite readily. Please spend some time over there, and consider buying the book Java Concurrency in Practice, which is a great resource! Gregg Wonderly -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-diff.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080103/821fbd7f/attachment-0026.txt From gergg at cox.net Thu Jan 3 15:25:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 03 Jan 2008 16:25:10 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <477D60C6.4050503@cox.net> Trent Jarvi wrote: > I'm trying the patch now with a testcase. Assuming it spins overnight > without issue, it looks like a winner. Revisiting Uncle Georges > suggestion of using > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is attractive > but adds yet another obstical for people using older (1.4) JREs. Another point to make on this issue is that JVMs prior to 1.5 will not correctly manage concurrency issues through the use of volatile. So, you have to do things very differently for loops such as the following, which is broken code structure, that only works on uniprocessors, but it seems to popup in existing Java software repeatedly. void someMethod() { while( foo > 0 ) { ... normal body of loop } } synchronized void someOtherMethod() { foo++; } synchronized void yetAnotherMethod() { foo--; } The while loop, if executed in a thread different than one executing the other two methods, will have problems with the visibility of changes to foo because it is not synchronized. You can't synchronize the someMethod() body without locking out calls to someOtherMethod() and yetAnotherMethod(). So, you have to write the code as in the following void someMethod() { while( true ) { synchronized(this) { if( foo <= 0 ) break; } ... normal body of loop } } It's important to understand how multi-core processors will suddenly make old software break in this regard. In Java 1.5, the Sun compiler implements the previously mentioned optimization based on the JMM spec changes that make volatile work correctly. That is, it will rewrite loops which are parameterized by non-volatile, unsynchronized reads to be while(true) as in class foo implements Runnable { boolean done; public void run() { while(!done) { ... } } public void shutdown() { done = true; } } which is incorrect software in a multi threaded environment (run() will typically be executed in a different thread than shutdown(), but on a uniprocessor, that different thread is a virtual thread which uses the same cache etc. The rewritten loop will be ... public void run() { if( done ) return; while( true ) { ... } } ... because it the optimizer will see that done is never written in the loop, and because it's not volatile, nor is it accessed in a synchronized context, could it safely be changed in another thread. This will cause seemingly correct software that run fine on 1.4 or a uniprocessor to suddenly break on 1.5 or a multi-core/hyper-threaded CPU. Gregg Wonderly Gregg Wonderly From timkcho at gmail.com Thu Jan 3 15:35:06 2008 From: timkcho at gmail.com (Tim Ho) Date: Fri, 4 Jan 2008 09:35:06 +1100 Subject: [Rxtx] Disable the printout of the version info Message-ID: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Hi, Is there a way to tell rxtx not to display the version info when use: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 ? Thanks. Tim From tjarvi at qbang.org Thu Jan 3 16:21:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:21:34 -0700 (MST) Subject: [Rxtx] Disable the printout of the version info In-Reply-To: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> References: <6122fe280801031435k640dfe80l1bfcf1db38c3f10a@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Tim Ho wrote: > Hi, > > Is there a way to tell rxtx not to display the version info when use: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > ? > > Thanks. > Tim The printing of the rxtx Version is hard coded in rxtx-2.1-7 RXTXCommDriver.java: private final static boolean devel = true; It will be disabled by default in future releases. We used to have many problems with people mixing rxtx 2.0 and 2.1 java and native libraries... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 3 16:30:46 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Jan 2008 16:30:46 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <477D5D4E.4040902@cox.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Gregg Wonderly wrote: > Trent Jarvi wrote: >> If George or you would like to prepare a patch to try, we can all spin it >> and discuss. It is probably not that bad to do. It would be nice to get >> rid of the extra code in there if we can do it safely. > > Attached is a patch which corrects the concurrency issues with RXTXPort.java. > I've made some changes which, ultimately may not be needed, but my changes > make the class safe for concurrency. The use of volatile is required for any > variable which may be read in one thread, unsynchronized, while it is written > in another thread. The loop, waiting for IOLocked to be zero would not > terminate in the typical case because the compiler would optimize it to > > if( IOLocked != 0 ) { > while( true ) { > ... > } > } > > because it is not volatile, no synchronized access occurs, and no writes to > the value occur within that loop. > > Please apply this diff and see what happens. I don't have a test environment > here, but these change should rectify any concurrency issues with this class. > > From a simple perspective, every class level variable in a java class should > either be declared final or volatile to be concurrency SAFE (as opposed to > optimally correct). If you understand the flow of code execution, and can be > assured that only a single thread ever accesses a particular class variable > (or it is always synchronized on the same object reference) then you can > avoid the use of volatile which will cause caching related synchronizations > to occur on each reference. > > The AtomicInteger etc classes are designed to avoid the synchronization that > volatile forces by using CAS spins to update values as in > > while( !CAS( A, A+1 ) ); > > instead of the concurrency killer > > synchronized( cache ) { > a = a+1; > } > > Multi-core processors have brought about a whole new potential for > performance. Unfortunately, software systems like Java don't provide you > with "always correct" operation because we still think it's more important to > optimize performance over guaranteed correctness. > > The concurrency-interest mailing list has a wealth of knowledgeable people, > including Doug Lea, all who can answer concurrency questions quite readily. > Please spend some time over there, and consider buying the book Java > Concurrency in Practice, which is a great resource! > Thanks for the explanation Gregg, I'll patch and start a test spin then reread your posts when I get home to make sure I understand the possible implications in rxtx. It is nice to know there is an open group on top of the issues. The time spent working through them with a blank slate is never rewarding. It also looks like I'm signed up for a book :) The previous patch I mentioned trying last night did work. We did not run any performance testing (that needs work). I'll post tomorrow to let everyone know how this one goes. -- Trent Jarvi tjarvi at qbang.org From beat.arnet at gmail.com Thu Jan 3 19:23:35 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Thu, 03 Jan 2008 21:23:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> Message-ID: <477D98A7.3060002@gmail.com> Trent Jarvi wrote: > On Wed, 2 Jan 2008, Beat Arnet wrote: > >> Trent Jarvi wrote: >>> On Mon, 10 Dec 2007, Daniel Wippermann wrote: >>> >>> >>>> Hi everone, >>>> >>>> >>>>> Hi all, >>>>> >>>>>> The IOLocked is a flag to indicate that a read/write I/O >>>>>> operation is in >>>>>> progress. it does not lockout the other from happening >>>>>> simultaneously. >>>>>> The synchronize read() does prevent simultaneous reads from multiple >>>>>> threads. >>>>>> The IOLocked indicator does prevent the close() from starting up, as >>>>>> close() waits for the IOLock value to become 0. The presumption >>>>>> is that >>>>>> the application's reads/writes will cease because the application >>>>>> has >>>>>> issued a close(). You wouldnt issue any further I/O after the >>>>>> close - >>>>>> would you? >>>>>> >>>>> You are completely right, I never meant to imply something >>>>> different. The IOLocked shall not lock concurrent reads or >>>>> concurrents writes away, but be a signal for the close method that >>>>> some read or write is still underway and it has to wait for them >>>>> to finish. >>>>> But the original question was, why the IOLocked variable has a >>>>> value != 0 ALTHOUGH all read and write activities have ceased >>>>> quite a while ago? And there were only two threads involved: on >>>>> one side the thread that called open() and write() and on the >>>>> other side the RXTX monitor thread that calling read(). No >>>>> multiple reads or writes! Only a parallel write while reading. But >>>>> that cannot be forbidden since we talk about an USART. Or am I >>>>> wrong? Is there a problem to to have one read() and one write() >>>>> run simulatenously? >>>>> If that case is an allowed one, IOLocked has to be synchronized >>>>> because it is altered in read() and write(). >>>>> >>>> I've prepared a patch to RXTXPort.java to help me outline my point >>>> of view in this discussion. It's attached to this posting. >>>> >>>> In general, three things have been done: >>>> >>>> 1) A new variable "IOLockedMutex" is introduced. It's only purpose >>>> is to be passed as a parameter to the synchronized statement. >>>> >>>> 2) Every "IOLocked++" is encapsulated by that said synchronized block >>>> >>>> 3) In some methods there were multiple "IOLocked--". Those have all >>>> been substituted by a one synchronized "IOLocked--" which is >>>> processed in a "finally" statement that handles all exceptions from >>>> right after "IOLocked++" till the end of the method. >>>> >>>> So every occurence or variation of the sequence: >>>> >>>> >>>>> IOLocked++; >>>>> waitForTheNativeCodeSilly(); >>>>> try { >>>>> // something method specific here >>>>> } catch (IOException ex) { >>>>> IOLocked--; >>>>> throw ex; >>>>> } >>>>> IOLocked--; >>>>> >>>> has been replaced by: >>>> >>>> >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked++; >>>>> } >>>>> try { >>>>> waitForTheNativeCodeSilly(); >>>>> // something method specific here >>>>> } finally { >>>>> synchronized (IOLockedMutex) { >>>>> IOLocked--; >>>>> } >>>>> } >>>>> >>>> In my opinion that chance has no impact on the surrounding >>>> application. It wont block away one function call if another one is >>>> running, it only ensures, that only one thread alters the IOLocked >>>> variable at any given time. So you could have one polling read() >>>> and one write() action in parallel without interference. >>>> >>>> In the hope, that I haven't abused your patience too much :) >>>> Daniel >>>> >>>> >>>> >>> >>> Thanks Daniel, >>> >>> I'm trying the patch now with a testcase. Assuming it spins >>> overnight without issue, it looks like a winner. Revisiting Uncle >>> Georges suggestion of using >>> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() is >>> attractive but adds yet another obstical for people using older >>> (1.4) JREs. >>> >>> >> All, >> While the patch proposed by Daniel seems to work fine, it brought the >> CPU of my computer to a grinding halt (both with synchronized >> statements and AtomicIntegers). What do you think about George's (?) >> suggestion of getting rid of IOLocked altogether? >> >> Beat Arnet >> >> > > Hi Beat, > > While I like the idea of close really closing on demand, I'm afraid of > the possible places we may 'squirt' all sorts of interesting messages > and exceptions into production apps. Those that have seen the code can > probably relate to how we learned about the various issues after > coding those methods. Close used to do as you would like. I think it > is possible to go back to that behavior since identifying other > sources of problems. > > I would not expect the cpu to jump. I'll try to confirm it tomorrow. > Which OS are you running on? I'm guessing you are doing frequent, > small reads and writes? > > If George or you would like to prepare a patch to try, we can all spin > it and discuss. It is probably not that bad to do. It would be nice to > get rid of the extra code in there if we can do it safely. > > -- > Trent Jarvi > tjarvi at qbang.org > Hi Trent, I ran my tests on an Windows XP machine. Yes, my code is doing frequent one-byte writes. I would be more than happy to test a specific patch on my machine. Regards, Beat From tjarvi at qbang.org Fri Jan 4 11:52:17 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 11:52:17 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: On Thu, 3 Jan 2008, Trent Jarvi wrote: > On Thu, 3 Jan 2008, Gregg Wonderly wrote: > >> Trent Jarvi wrote: >>> If George or you would like to prepare a patch to try, we can all spin it >>> and discuss. It is probably not that bad to do. It would be nice to get >>> rid of the extra code in there if we can do it safely. >> >> Attached is a patch which corrects the concurrency issues with >> RXTXPort.java. I've made some changes which, ultimately may not be needed, >> but my changes make the class safe for concurrency. The use of volatile is >> required for any variable which may be read in one thread, unsynchronized, >> while it is written in another thread. The loop, waiting for IOLocked to >> be zero would not terminate in the typical case because the compiler would >> optimize it to >> >> if( IOLocked != 0 ) { >> while( true ) { >> ... >> } >> } >> >> because it is not volatile, no synchronized access occurs, and no writes to >> the value occur within that loop. >> >> Please apply this diff and see what happens. I don't have a test >> environment here, but these change should rectify any concurrency issues >> with this class. >> >> From a simple perspective, every class level variable in a java class >> should either be declared final or volatile to be concurrency SAFE (as >> opposed to optimally correct). If you understand the flow of code >> execution, and can be assured that only a single thread ever accesses a >> particular class variable (or it is always synchronized on the same object >> reference) then you can avoid the use of volatile which will cause caching >> related synchronizations to occur on each reference. >> >> The AtomicInteger etc classes are designed to avoid the synchronization >> that volatile forces by using CAS spins to update values as in >> >> while( !CAS( A, A+1 ) ); >> >> instead of the concurrency killer >> >> synchronized( cache ) { >> a = a+1; >> } >> >> Multi-core processors have brought about a whole new potential for >> performance. Unfortunately, software systems like Java don't provide you >> with "always correct" operation because we still think it's more important >> to optimize performance over guaranteed correctness. >> >> The concurrency-interest mailing list has a wealth of knowledgeable people, >> including Doug Lea, all who can answer concurrency questions quite readily. >> Please spend some time over there, and consider buying the book Java >> Concurrency in Practice, which is a great resource! >> > > Thanks for the explanation Gregg, > > I'll patch and start a test spin then reread your posts when I get home to > make sure I understand the possible implications in rxtx. > > It is nice to know there is an open group on top of the issues. The time > spent working through them with a blank slate is never rewarding. It also > looks like I'm signed up for a book :) > > The previous patch I mentioned trying last night did work. We did not run > any performance testing (that needs work). I'll post tomorrow to let > everyone know how this one goes. > This patch appears to resolve the issue also. I have only verified the lockup on close on multicore/smp systems. It would be interesting to see how their performance does compare with small reads and writes. I'll be looking into the performance with for my needs in mind but encourage others to voice their concerns/... with the options present before we decide on a final solution. -- Trent Jarvi tjarvi at qbang.org From jamesbrannan at earthlink.net Fri Jan 4 20:40:16 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Fri, 4 Jan 2008 22:40:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-2200816534016765@earthlink.net> I posted a somwhat obtuse question before about RXTX's speed. Here's something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? processor but more then fast enough. See my previous email for description of how I count pulses.... I removed RXTX from my local project folders and followed install instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, RXTX simply doesn't seem to be keeping up with cts/dsr events. The numbers fluctuate wildly and are on the low side, with debug statements you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic) Now, I *know* Sun's javax.comm for windows works, as I've had been using it for about 1 year now, the speed and cadence (ie. cts and dsr are right on the money with my external bike computer on my handlebar). And the debug prints are pretty consistent.... Today I changed back to javax.comm and my software tracks speed and cadence accurately again. Below is my source code, if someone could help out I'd credit you in the website and the comments. The whole thing behind IntervalTrack was that it is to be cross-platform and dirt cheap (parts are opensource, part is nagware). It was to run on Linux, Mac, and Windows....and I dont want to have to use the commercial serialport IO, if at all possible. I want to keep this software as dirt-cheap nagware. Thanks for any help....I believe this problem is worth someone responding, as its kind of a different way of using CTS and DSR (I think)...of course I'm a java j3ee - move data from one place to another serf - in my day job, so I dont know much about hardware :-) Oh, I should also mention that I tried creating two consumer threads, where this class only called the thread's doDsr and doCts methods, performance was pretty much unaffected if not worse..... Thanks, James A. Brannan, Impulse Software ----------------------------------------------------------------------------------------------------------------- package com.intervaltrack.serialio; import javax.comm.*; //import gnu.io.*; import java.util.Enumeration; import java.util.ArrayList; import java.util.TooManyListenersException; /** * ----------------------------------------------------------------------------------------------- * @author James Brannan - Impulse Software * * Software created by Impulse Software. Feel free to copy and modify this * class as you wish. Provided you didnt get it from reverse-engineering * IntervalTrack PC Cycling Computer - which is not open source. * * This class is covered under the LGPL. * * Since I pretty much got the algorithm, inspiration, and electronic plans for this * method of speed and cadence from the open-source spinner software, figured its only * fair this part of IntervalTrack is open-source too. Especially as its not rocket-science. * * This software is not guaranteed and I'm not liable for damages if you use it. * You can ruin your computer by messing with electricity and the serial port! * * Monitor a serial port for CTS and DSR events. Every CTS event changing state * represents a single rotation of the wheel, the bike has travelled the wheel size in mm * in distance. Speed is the time delta and the size of the wheel. * ((double)3.6 * (double)this.getWheelSizeInMM()) / dblDeltaSpeedTime; * * Every DSR event changing state represents a single rotation of the pedals (rpm). * Cadence is time delta. * this.dblCadence = 60000/dblDeltaCadenceTime; * * Basically all the hardware is doing, from a layman's point of view, is sending positive * voltage from RTS to CTS and DSR. But, because of the sensors being wired to the corresponding * loopbacks, it "shorts" the continuos pulse power from RTS to CTS and from RTS to DTR, causing * the circuit to open/close every time a magnet is crossed across the sensors wired to the * serial port....or something like that, I'll update this comment after taking a community college * electronics course and I know what I'm doing electronics wise ;-) * * ------------------------------------------------------------------------------------------------------- */ public class SerialConnection implements SerialPortEventListener { private CommPortIdentifier portID; private SerialPort serialPort; private String strComPortAsString = null; private boolean oldCTSValue = false; private boolean oldDSRValue = false; private double dblSpeedT1 = 0.0; private double dblCadenceT1 = 0.0; private double dblSpeedKmPerHour = 0.0; private double dblCadence = 0.0; private double wheelSizeInMM = 0.0; public SerialConnection(String strComPort, double wheelsize) throws PortInUseException, TooManyListenersException, UnsupportedCommOperationException, NoSuchPortException { this.strComPortAsString = strComPort; this.wheelSizeInMM = wheelsize; this.dblCadenceT1 = System.currentTimeMillis(); this.dblSpeedT1 = this.dblCadenceT1; this.setComPortIdentifier(strComPort); serialPort = (SerialPort)portID.open("IntervalTrack", 0); serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //need to notify on DSR and CTS serialPort.notifyOnDSR(true); serialPort.notifyOnCTS(true); serialPort.addEventListener(this); //set dtr to false - making it negative power so can //use as negative for the circuit serialPort.setDTR(false); //set RTS to true - making it positive so its sending power serialPort.setRTS(true); //no flow control - not needed //serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); } //SerialConnection is the event producer, when it gets a drs or cts //it notifies its consumers who then do the calculations, not doing //it here for fear that the processing could cause missed rotations //if speed and/or cadence is too fast, even though on a bike probably //not that problematic public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.DSR: if(e.getNewValue()==false && oldDSRValue == true) doDSR(); oldDSRValue = e.getNewValue(); break; case SerialPortEvent.CTS: if(e.getNewValue()==false && oldCTSValue == true) doCTS(); oldCTSValue = e.getNewValue(); break; } } private void doDSR() { double dblCadenceT2 = System.currentTimeMillis(); double dblDeltaCadenceTime = dblCadenceT2 - dblCadenceT1; if(dblDeltaCadenceTime == 0) { dblCadenceT1 = System.currentTimeMillis(); return; } dblCadence = 60000/dblDeltaCadenceTime; dblCadenceT1 = dblCadenceT2; } public void doCTS() { //calculate the change in system time from last cts event double dblSpeedT2 = System.currentTimeMillis(); double dblDeltaSpeedTime = dblSpeedT2 - dblSpeedT1; //if delta is zero then just ignore it to avoid divide by zero if (dblDeltaSpeedTime == 0.0) { dblSpeedT1 = System.currentTimeMillis(); return; } //calculate the instantaneous speed for the revolution based on wheel size dblSpeedKmPerHour = ((double)3.6 * (double)getWheelSizeInMM()) / dblDeltaSpeedTime; dblSpeedT1 = dblSpeedT2; System.out.println("spd: " + dblSpeedKmPerHour); } public static String[] getPorts() { Enumeration comPorts = CommPortIdentifier.getPortIdentifiers(); ArrayList lst = new ArrayList(); while(comPorts.hasMoreElements()) { CommPortIdentifier x = (CommPortIdentifier)comPorts.nextElement(); lst.add(x.getName()); } String[] vals = new String[lst.size()]; for(int i = 0; i < lst.size(); i++) { vals[i] = (String)lst.get(i); } return vals; } public void closePort() { this.serialPort.close(); this.serialPort = null; } public double getDblSpeedKmPerHour() { double toRet = dblSpeedKmPerHour; return toRet; } public double getWheelSizeInMM() { return wheelSizeInMM; } public double getDblCadence() { double toRet = dblCadence; return toRet; } public long lngMillisecondsFromLastSpeedPulse(){ return System.currentTimeMillis() - (long)this.dblSpeedT1; } public long longMillisecondsFromLastCadencePulse(){ return System.currentTimeMillis() - (long)this.dblCadenceT1 ; } public String getSerialPortAsString(){return this.strComPortAsString;} public void setComPortIdentifier(String strCOMPort) throws NoSuchPortException { this.portID = CommPortIdentifier.getPortIdentifier(strCOMPort); } } James Brannan jamesbrannan at earthlink.net EarthLink Revolves Around You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080104/565e9076/attachment-0025.html From tjarvi at qbang.org Fri Jan 4 21:07:11 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 4 Jan 2008 21:07:11 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-2200816534016765@earthlink.net> References: <380-2200816534016765@earthlink.net> Message-ID: On Fri, 4 Jan 2008, James Brannan wrote: > I posted a somwhat obtuse question before about RXTX's speed. Here's > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > processor but more then fast enough. See my previous email for > description of how I count pulses.... > > I removed RXTX from my local project folders and followed install > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > numbers fluctuate wildly and are on the low side, with debug statements > you can literally see it print a bunch of numbers, pause for a second or > two, print a bunch of numbers, etc. (very sporadic) > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > it for about 1 year now, the speed and cadence (ie. cts and dsr are > right on the money with my external bike computer on my handlebar). > And the debug prints are pretty consistent.... > > Today I changed back to javax.comm and my software tracks speed and > cadence accurately again. Below is my source code, if someone could > help out I'd credit you in the website and the comments. The whole > thing behind IntervalTrack was that it is to be cross-platform and dirt > cheap (parts are opensource, part is nagware). It was to run on Linux, > Mac, and Windows....and I dont want to have to use the commercial > serialport IO, if at all possible. I want to keep this software as > dirt-cheap nagware. > > Thanks for any help....I believe this problem is worth someone > responding, as its kind of a different way of using CTS and DSR (I > think)...of course I'm a java j3ee - move data from one place to another > serf - in my day job, so I dont know much about hardware :-) > > Oh, I should also mention that I tried creating two consumer threads, > where this class only called the thread's doDsr and doCts methods, > performance was pretty much unaffected if not worse..... > > Free software means you are free to modify it, not that it wont cost you time if it does not work the way you want :) That said, people trying to modify the source often find help at that point. Often problems like this tend to be solved if the itch is bothering someone enough. Obviously we do not know what Sun does or does not do. Are you comparing apples to apples? When you use rxtx, is it on the same windows system? A one second pause sounds unusual. The last time I looked at events, the round trip for writing a byte to a loopback connection when a data available events occured was about 10 ms. With rxtx, it simplifies the problem significantly if the problem is observable under Linux or Solaris. Windows is another layer of code inside. Mac uses USB dongles usually which presents other variables. It may be that the thread the eventLoop is running on needs a higher priority. I do not think we set priorities at all. This is triggered from RXTXPort.java. You only have the thread priorities and a fairly simple eventloop() native method in serialImp.c doing the events. If you can reproduce this on Linux, it should be easy to tinker with. Once that is working, you probably find windows falls into place. You have a reproducable situation which is half the game. If you want to reproduce it somehow with a loopback connector and show a testcase, others may be able to look at the same issue. You can assert pins and they do loop back with a loopback connection. Once it is measureable/testable, that opens up a means of quickly determining if modifications help. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 06:16:00 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 08:16:00 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <477C49D2.5050408@gmail.com> <477D5D4E.4040902@cox.net> Message-ID: <477F8310.1000906@gatworks.com> Trent Jarvi wrote: > On Thu, 3 Jan 2008, Trent Jarvi wrote: > >> On Thu, 3 Jan 2008, Gregg Wonderly wrote: >> >>> Trent Jarvi wrote: >>>> If George or you would like to prepare a patch to try, we can all spin it >>>> and discuss. It is probably not that bad to do. It would be nice to get Some issues: 1) fd = 0; as a flag does not work. the "0" is bad bec its a valid UNIX file descriptor. But I needed to have a synchronized close, but not yet close the I/O channel. What are valid FD's on windoz? 2) if ( speed == 0 ) return ? Are there commapi specs for this ? It seems sooooo wroooonnnnnnngggggggggggg! 3) If the channel is closed, but you are still reading/writing, do you really get an IOException? are there commapi specs? 4) Synchronized reads are gone 5) as well as the synchronized isavailable. If you really - really want safe coordinated routines that plays nice, then go create an "extends inputstream" subclass and pass this class to all the threads. Later tonight I'll plug this into my software to see if any ill'effects. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080105/da997d0f/attachment-0025.pl From jamesbrannan at earthlink.net Sat Jan 5 07:49:39 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 09:49:39 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165144939203@earthlink.net> Sorry I posted the question....ask a question about software and get chastized for trying to develop shareware. If RXTX can't keep up with the events....then I'll be forced to go with the more expensive alternative....which I didnt want to do. I thought my project is an interesting application of RXTX and maybe warranted a little help. Thats all I was saying, I wasnt trying to threaten, just trying to plead for some help....maybe I did it the wrong way. I would help if I could, but I'm not a c/c++ programmer. But, all this stuff aside, all I was looking for was some ideas on why this simple loop doesnt work. Condensing the previous response I gather that its probably has something to do with the thread priorities and that I'd have to dive into the C/C++ code on Linux to figure it out - neither of which I'm qualified to do. You are correct, it wasn't a second more like 10ms, but that's too slow. This was all on the same machine. I am however, going to install my stuff onto Linux and see if RXTX has a problem on Linux. Dude, I'm sure alot of big corporations are making money off your product, so why chastize someone who wants to charge 20 bucks as nagware to a product that is using rxtx in it? The 20 bucks isnt for the RXTX serial port stuff, hell its not even for the integrated MP3 playback or the integrated MPlayer DVD playback - both offered as free opensource plugins to my software - its the other features the software offers.... James A. Brannan - > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From jamesbrannan at earthlink.net Sat Jan 5 08:18:20 2008 From: jamesbrannan at earthlink.net (James Brannan) Date: Sat, 5 Jan 2008 10:18:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? Message-ID: <380-22008165151820890@earthlink.net> Okay, maybe I'm being too sensitive... Given that you say the events are pretty much confined to this dll, I'll take a look at it on Linux, see what's going on. I'll break out my C/C++ books gathering dust somewhere. Chances are though, I'll just make a mess of things, I'm a j2ee programmer after all - i.e. if there ain't an API for it, then it can't be done ;-) BTW, I just priced out the cost of serialPort to the consumer, 99 cents, but I'd still much rather use opensource for this part of the application. >It may be that the thread the eventLoop is running on needs a higher >priority. I do not think we set priorities at all. This is triggered >from RXTXPort.java. You only have the thread priorities and a fairly >simple eventloop() native method in serialImp.c doing the events. If you >can reproduce this on Linux, it should be easy to tinker with. Once that >is working, you probably find windows falls into place. > [Original Message] > From: Trent Jarvi > To: James Brannan > Cc: > Date: 1/4/2008 11:07:13 PM > Subject: Re: [Rxtx] RXTX vs. Sun - Sun's Faster? > > On Fri, 4 Jan 2008, James Brannan wrote: > > > I posted a somwhat obtuse question before about RXTX's speed. Here's > > something more concrete. Windows 2000, JDK 1.5, 2 gig of ram, ?? > > processor but more then fast enough. See my previous email for > > description of how I count pulses.... > > > > I removed RXTX from my local project folders and followed install > > instructions for RXTX (i.e. putting it in the ext fold etc.)....no dice, > > RXTX simply doesn't seem to be keeping up with cts/dsr events. The > > numbers fluctuate wildly and are on the low side, with debug statements > > you can literally see it print a bunch of numbers, pause for a second or > > two, print a bunch of numbers, etc. (very sporadic) > > > > Now, I *know* Sun's javax.comm for windows works, as I've had been using > > it for about 1 year now, the speed and cadence (ie. cts and dsr are > > right on the money with my external bike computer on my handlebar). > > And the debug prints are pretty consistent.... > > > > Today I changed back to javax.comm and my software tracks speed and > > cadence accurately again. Below is my source code, if someone could > > help out I'd credit you in the website and the comments. The whole > > thing behind IntervalTrack was that it is to be cross-platform and dirt > > cheap (parts are opensource, part is nagware). It was to run on Linux, > > Mac, and Windows....and I dont want to have to use the commercial > > serialport IO, if at all possible. I want to keep this software as > > dirt-cheap nagware. > > > > Thanks for any help....I believe this problem is worth someone > > responding, as its kind of a different way of using CTS and DSR (I > > think)...of course I'm a java j3ee - move data from one place to another > > serf - in my day job, so I dont know much about hardware :-) > > > > Oh, I should also mention that I tried creating two consumer threads, > > where this class only called the thread's doDsr and doCts methods, > > performance was pretty much unaffected if not worse..... > > > > > > Free software means you are free to modify it, not that it wont cost you > time if it does not work the way you want :) That said, people trying to > modify the source often find help at that point. > > Often problems like this tend to be solved if the itch is bothering > someone enough. Obviously we do not know what Sun does or does not do. > > Are you comparing apples to apples? When you use rxtx, is it on the same > windows system? > > A one second pause sounds unusual. The last time I looked at events, the > round trip for writing a byte to a loopback connection when a data > available events occured was about 10 ms. > > With rxtx, it simplifies the problem significantly if the problem is > observable under Linux or Solaris. Windows is another layer of code > inside. Mac uses USB dongles usually which presents other variables. > > It may be that the thread the eventLoop is running on needs a higher > priority. I do not think we set priorities at all. This is triggered > from RXTXPort.java. You only have the thread priorities and a fairly > simple eventloop() native method in serialImp.c doing the events. If you > can reproduce this on Linux, it should be easy to tinker with. Once that > is working, you probably find windows falls into place. > > You have a reproducable situation which is half the game. If you want to > reproduce it somehow with a loopback connector and show a testcase, others > may be able to look at the same issue. You can assert pins and they do > loop back with a loopback connection. Once it is measureable/testable, > that opens up a means of quickly determining if modifications help. > > -- > Trent Jarvi > tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 09:19:20 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:19:20 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165144939203@earthlink.net> References: <380-22008165144939203@earthlink.net> Message-ID: <477FAE08.5010009@gatworks.com> James Brannan wrote: > Sorry I posted the question....ask a question about software and get > chastized for trying to develop shareware. If RXTX can't keep up with the If u really really want to get singed, try the qmail group! Since you are not going to get real-time, at best you are going to get quantum slices of scheduling time. The kernel scheduler determines which process, thread, .. gets cpu time. Java does not really help in scheduling. The user can help by setting thread priority. generally priority cant be set higher, but can be set lower. So a task in the runnable state, and has higher priority, and does not fall out of favor because of 'fairness' factors, will be run next. Having an event thread at low priority is bad news, because it may not get a slice of time before it can detect the real-time event ( change of dtr, cts, .... ). Even at normal priority, it will be competing with other threads for slices of time. So to be able to detect the real-time status change of an electrical signal, the change has to be detected when the probability of getting a time slice is just about guaranteed. As for the status signals ( cts/rts dtr/?tr ) I am not too sure how they are propagated in linux. Or how long it takes for the status change to arrive. Its not something I had to worry about - so far. Not to mention I dont have the tools to test. From netbeans at gatworks.com Sat Jan 5 09:32:23 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 11:32:23 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <477FB117.1050707@gatworks.com> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Why? edit the RXTX code. If you can find the RXTX code that detects the status change, timestamp the status change, and store that info into a buffer. When buffer gets full, print out the interval between reported events. If interval not uniform, then dont report the event to rxtx et al ( ie just reset and return so another event can be generated. ) If interval is still uneven, then thats not RXTX. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) So u confess to being infected with j2ee. It explains a lot! :} From tjarvi at qbang.org Sat Jan 5 15:21:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 15:21:54 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <477FAE08.5010009@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Having an event thread at low priority is bad news, because it may not get a > slice of time before it can detect the real-time event ( change of dtr, cts, > .... ). Even at normal priority, it will be competing with other threads for > slices of time. This should be (?) easy to test. In RXTXPort.java the constructor creates the monitor thread which is the eventLoop. We can change the priority there (around line 100). // try { fd = open( name ); this.name = name; MonitorThreadLock = true; monThread = new MonitorThread(); monThread.start(); monThread.setPriority( Thread.MIN_PRIORITY ); /* or */ monThread.setPriority( Thread.MAX_PRIORITY ); waitForTheNativeCodeSilly(); MonitorThreadAlive=true; // } catch ( PortInUseException e ){} I do not know if the native eventLoop() priority would need to be modified as a native system thread or we would just leave that as something for the JVM to manage. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 17:13:14 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 19:13:14 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> Message-ID: <47801D1A.5010502@gatworks.com> Trent Jarvi wrote: We can change the > priority there (around line 100). > :)))) The issue with thread priority is that it conforms to OS standards ( and not java standards ) . On most UNIX's, task priority is at a normal setting, or can be made lower. To Obtain max priority ( or somewhere inbetween normal and max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except in green threads ) to do any scheduling. At best, the JVM can only suggest to the OS-scheduler to give it a priority in scheduling ( amongst all the 'runnable' tasks). you can try max_priority, but that will be ignored by the os ( presuming u dont have privs ) . ur fait will always be with the dictated by what has been *taught to the task scheduler*. To get better response, u lower the priority ( slightly ) of the other threads so that if the event thread is made runnable, it will be scheduled first. BUT i suspect, all in all, that this issue is because the select() is *not* (as far as i can superficially see ) used to detect exceptions, of which I hope includes the serial port status changes. BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet proofed, may cause the system to become unresponsive if the thread begins to spin. From tjarvi at qbang.org Sat Jan 5 17:30:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 17:30:21 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47801D1A.5010502@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: > Trent Jarvi wrote: > We can change the >> priority there (around line 100). >> > :)))) > The issue with thread priority is that it conforms to OS standards ( and not > java standards ) . On most UNIX's, task priority is at a normal setting, or > can be made lower. To Obtain max priority ( or somewhere inbetween normal and > max ) , u need privs ( see "man 1 nice" ) . Its not a java function ( except > in green threads ) to do any scheduling. At best, the JVM can only suggest to > the OS-scheduler to give it a priority in scheduling ( amongst all the > 'runnable' tasks). > > you can try max_priority, but that will be ignored by the os ( presuming u > dont have privs ) . ur fait will always be with the dictated by what has been > *taught to the task scheduler*. > To get better response, u lower the priority ( slightly ) of the other > threads so that if the event thread is made runnable, it will be scheduled > first. > > > BUT i suspect, all in all, that this issue is because the select() is *not* > (as far as i can superficially see ) used to detect exceptions, of which I > hope includes the serial port status changes. > > BTW setting a thread to MAX_PRIORITY, if you could, before its been bullet > proofed, may cause the system to become unresponsive if the thread begins to > spin. > As I read the Java documentation on this, they are as clear as mud. This is obviously OS specific, but you will not find one OS mentioned. Regardless. If it is true that an event can take 1 second, this is presumably not a OS thread priority issue. 0.1 seconds? Maybe. I've never seen proof that the 1 second is real. With things like events, It is very easy on windows to see when rxtx will fail. You fire up the task manager and watch the CPU load. 100% CPU? Boom. Usually it is not rxtx causing the load. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Jan 5 18:55:49 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 20:55:49 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> Message-ID: <47803525.1050403@gatworks.com> > thread begins to spin. >> > > As I read the Java documentation on this, they are as clear as mud. > This is obviously OS specific, but you will not find one OS mentioned. For native threads, on unix, maybe this will help: "man sched_setscheduler" > > Regardless. If it is true that an event can take 1 second, this is > presumably not a OS thread priority issue. 0.1 seconds? Maybe. ?? Sorry lost the context here. why should an event take one second? Anyway, its better to see if status changes are handled as soon as possible in rxtx, before messing with scheduling issues. From tjarvi at qbang.org Sat Jan 5 19:01:18 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 5 Jan 2008 19:01:18 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47803525.1050403@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: On Sat, 5 Jan 2008, U. George wrote: >> thread begins to spin. >>> >> >> As I read the Java documentation on this, they are as clear as mud. This >> is obviously OS specific, but you will not find one OS mentioned. > For native threads, on unix, maybe this will help: "man sched_setscheduler" >> >> Regardless. If it is true that an event can take 1 second, this is >> presumably not a OS thread priority issue. 0.1 seconds? Maybe. > ?? Sorry lost the context here. why should an event take one second? > > > Anyway, its better to see if status changes are handled as soon as possible > in rxtx, before messing with scheduling issues. > per the original report: " you can literally see it print a bunch of numbers, pause for a second or two, print a bunch of numbers, etc. (very sporadic)" From netbeans at gatworks.com Sat Jan 5 19:43:12 2008 From: netbeans at gatworks.com (U. George) Date: Sat, 05 Jan 2008 21:43:12 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> Message-ID: <47804040.3040508@gatworks.com> >> Anyway, its better to see if status changes are handled as soon as >> possible in rxtx, before messing with scheduling issues. >> > > per the original report: > > " you can literally see it print a bunch of numbers, pause > for a second or two, print a bunch of numbers, etc. (very sporadic)" > since i dont have hardware: > Why? edit the RXTX code. If you can find the RXTX code that detects the > status change, timestamp the status change, and store that info into a > buffer. When buffer gets full, print out the interval between reported > events. > If interval not uniform, then dont report the event to rxtx et al ( ie > just reset and return so another event can be generated. ) If interval > is still uneven, then thats not RXTX. From will.tatam at red61.com Sun Jan 6 06:00:01 2008 From: will.tatam at red61.com (Will Tatam) Date: Sun, 06 Jan 2008 13:00:01 +0000 Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> References: <6bpm1d$51c4do@toip4.srvr.bell.ca> <29788b250712170836q59e57b56kb3c697570f614bd5@mail.gmail.com> Message-ID: <4780D0D1.2020905@red61.com> F?bio Cristiano dos Anjos wrote: > Hi all, > > I finally had success building RXTX in windows. I had to reinstall > mingw (i think that the version i had was not complete), install > cygwin, change some directory entries in the script, and put some > directories in the PATH system variable > (C:\MinGW\bin;C:\lcc\bin;C:\cygwin\bin;C:\MinGW\libexec\gcc\mingw32\3.4.5). > > But I am still having some problems in using it. Every time I try to > open a port that is being user by other application, the > isCurrentlyUsed method returns false, and the UnsatisfiedLinkError is > thrown instead of the normal PortInUse exception, as shown below: > > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > gnu.io.CommPortIdentifier.native_psmisc_report_owner(Ljava/lang/String;)Ljava/lang/String; > at gnu.io.CommPortIdentifier.native_psmisc_report_owner(Native Method) > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:466) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptor(ReceptorFacade.java:344) > at > br.com.segware.sigmaProcessor.business.facade.ReceptorFacade.initializeReceptors(ReceptorFacade.java:277) > at > br.com.segware.sigmaProcessor.business.delegate.ReceptorDelegate.initializeReceptors(ReceptorDelegate.java:118) > at > br.com.segware.sigmaProcessor.view.panel.ReceptorPanel.(ReceptorPanel.java:93) > at br.com.segware.sigmaProcessor.view.MainUI.(MainUI.java:61) > at br.com.segware.sigmaProcessor.view.MainUI$6.run(MainUI.java:258) > at java.awt.event.InvocationEvent.dispatch(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > > Am I doing something wrong? > > Thanks in advance! > > F?bio > -------- > > Have you tried recompiling your java app against the new build of RXTX ? -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From lyon at docjava.com Mon Jan 7 06:31:38 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 07 Jan 2008 08:31:38 -0500 Subject: [Rxtx] binary build type Message-ID: Hi All, I have two kinds of libraries on the mac. One is PPC, the other is i386. Both have the same name. However, they are of different type. For example: file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle i386 Vs. file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O bundle ppc During the java.library.path search done during the native library linking phase, it is important for the loader to load the correct native libraries, or a run-time error occurs. Since the two libraries have IDENTICAL names, it is impossible to tell which is which, based on name alone. Is there a portable 100% Java way to determine arch of the binaries in a native library? Thanks! - Doug From j.kenneth.gentle at acm.org Mon Jan 7 07:59:04 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 7 Jan 2008 09:59:04 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <47804040.3040508@gatworks.com> References: <380-22008165144939203@earthlink.net> <477FAE08.5010009@gatworks.com> <47801D1A.5010502@gatworks.com> <47803525.1050403@gatworks.com> <47804040.3040508@gatworks.com> Message-ID: <670b66630801070659w43ed8df2ve43eb28547af250@mail.gmail.com> The "print a bunch of numbers, pause, ..." could very plausibly be buffering of the output to STDOUT/STDERR. I'm not clear if this is occurring in Java or C++, but in either case buffering can explain the sporadic pauses. IIRC, depending on the iostream class used, it may be waiting on a new line or buffer full before writing to STDOUT/STDERR. Ken On Jan 5, 2008 9:43 PM, U. George wrote: > >> Anyway, its better to see if status changes are handled as soon as > >> possible in rxtx, before messing with scheduling issues. > >> > > > > per the original report: > > > > " you can literally see it print a bunch of numbers, pause > > for a second or two, print a bunch of numbers, etc. (very sporadic)" > > > since i dont have hardware: > > Why? edit the RXTX code. If you can find the RXTX code that detects the > > status change, timestamp the status change, and store that info into a > > buffer. When buffer gets full, print out the interval between reported > > events. > > If interval not uniform, then dont report the event to rxtx et al ( ie > > just reset and return so another event can be generated. ) If interval > > is still uneven, then thats not RXTX. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- J. Kenneth Gentle (Ken) Gentle Software LLC Phone: 484.371.8137 Mobile: 302.547.7151 Email: ken.gentle at gentlesoftware.com Email: j.kenneth.gentle at acm.org www.gentlesoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080107/5b93af86/attachment-0022.html From will.tatam at red61.com Mon Jan 7 08:26:53 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 07 Jan 2008 15:26:53 +0000 Subject: [Rxtx] binary build type In-Reply-To: References: <47823085.80800@red61.com> Message-ID: <478244BD.8080109@red61.com> I have just skimmed though your reply, and I think I follow your logic, but am not a Java developer myself, i just deal with java packaging. The complexities you have outlined are exactly what I thought universal binaries are designed to support. It seams to me a much simpler idea to deal with the extra complexities of building a universal jnilib rather than complicate RXTX and your applicaiton and your JNLP. Ok building the universal might be an arse, but that will only be needed to be done once for the entire RXTX user community if you use their stock release or once per new release of RXTX if you have a customised package As for the whole windows/linux 32/64 i386/i686 issue, as you have already stated, these can be delt with by your installer/JWS Will Dr. Douglas Lyon wrote: > Hi Will, > Thank you for your prompt response. > > It is not always possible to build Fat binaries. > Normally, we would like to have a convention for the > PPC vs the i386 binary. What will we do when we compile > for i686? > > From the historical perspective of the JNI programmer, the > primary ARCH indicator has been the library name or library location. > > This is because: > System.mapLibraryName(s); > > Provides for a native library name that maps for the particular system. > When loading a shared library, JVM calls mapLibraryName(libName) to > convert libName to a platform specific name. On UNIX systems, this > call might return a file name with the wrong extension (for example, > libName.so rather than libName.a). > > There are two solutions to this problem; > Unique File Names or Unique File Locations. > > Unique File Names (every arch has a unique filename): > It has been proposed that we arrive at a standard file name for the > arch, this > would ease the identification of the correct, optimized binary. > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > mapLibraryName = "libNAME.so" > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > "libNAME.so" > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > "libNAME.jnilib" > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > mapLibraryName = "NAME.dll" > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > mapLibraryName = "libNAME.so" > > you will notice that Linux 32/64 and Solaris all use "libNAME.so"... > despite the architecture they are running on! > Alternate names: > G4: "libNAME.jnilib" > Mac x386: "libNAME-x86.jnilib" > Linux (i686): "name-linux-x86" > Linux (Intel/AMD 64): "name-linux-x86_64" > Linux (sparc): "name-linux-sparc" > Linux (PPC 32 bit): "name-linux-ppc" > Linux (PPC 64 bit): "name-linux-ppc_64" > Windows XP/Vista (i686): "name-windows-x86" > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > Sun Solaris (Blade): "name-sun-sparc" > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > Solution 2: Directory Names (each architecture lives in a specific > location). > > Basically, an invocation to System.load will have to be sanitized to > make use > of the architecture-based naming convention, or we can over-write the > system.library.path > at run time with a class-path byte-code hack. > public static void pathHack() throws NoSuchFieldException, > IllegalAccessException { > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > userPaths.setAccessible(true); > userPaths.set(null, null); > userPaths.setAccessible(true); > userPaths.set(null, null); > } > Making the userPaths alterable at runtime will enable modification of the > system.library.path. Then you can append a native path that is > architecture > specific: > public static void appendJavaLibraryPath(File path) { > if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + > "only directories are findable:" + path); > System.out.println("appending:" + path + " to > java.library.path"); > try { > pathHack(); > } catch (NoSuchFieldException e) { > e.printStackTrace(); > > } catch (IllegalAccessException e) { > e.printStackTrace(); > > } > String javaLibraryPath = "java.library.path"; > String newDirs = System.getProperty(javaLibraryPath) + > File.pathSeparatorChar + path; > System.setProperty(javaLibraryPath, newDirs); > System.out.println("java.library.path:" + > System.getProperty(javaLibraryPath)); > } > This is otherwise not generally accessible. > > The system.load obviates the need to hack the java library path, we > just write our > own native loader and make sure no one else called system.loadLibrary. > > From the webstart programmer point of view, the arch is used to direct > the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > We use the same name for all (native.jar) and just change the path > as an architecture-based dispatch. That seems cleaner, to me...but > perhaps > it is a matter of taste. > > What do you think of that? > > Thanks! > - Doug > >> Dr. Douglas Lyon wrote: >>> Hi All, >>> I have two kinds of libraries on the mac. One is PPC, the >>> other is i386. >>> >>> Both have the same name. However, they are of different type. >>> For example: >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle i386 >>> >>> Vs. >>> file librxtxSerial.jnilib >>> librxtxSerial.jnilib: Mach-O bundle ppc >>> >>> >>> During the java.library.path search done during the native library >>> linking phase, it is important for the loader to load the correct >>> native >>> libraries, or a run-time error occurs. >>> >>> Since the two libraries have IDENTICAL names, it is impossible to tell >>> which is which, based on name alone. >>> >>> Is there a portable 100% >>> Java way to determine arch of the binaries in a native library? >>> >>> Thanks! >>> - Doug >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> This is why you need a universal binary, see list archives >> >> -- >> Will Tatam >> Systems Architect >> Red61 >> >> 0845 867 2203 ext 103 > -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From Martin.Oberhuber at windriver.com Mon Jan 7 08:51:14 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 7 Jan 2008 16:51:14 +0100 Subject: [Rxtx] binary build type In-Reply-To: <478244BD.8080109@red61.com> References: <47823085.80800@red61.com> <478244BD.8080109@red61.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848040CEE90@ism-mail03.corp.ad.wrs.com> In fact, I think the downloadable pre-built binaries for RXTX are universal binaries, supporting both Intel and PPC in a single lib. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Will Tatam > Sent: Monday, January 07, 2008 4:27 PM > To: Dr. Douglas Lyon; rxtx at qbang.org > Subject: Re: [Rxtx] binary build type > > I have just skimmed though your reply, and I think I follow > your logic, but am not a Java developer myself, i just deal > with java packaging. > The complexities you have outlined are exactly what I thought > universal binaries are designed to support. It seams to me a > much simpler idea to deal with the extra complexities of > building a universal jnilib rather than complicate RXTX and > your applicaiton and your JNLP. > > Ok building the universal might be an arse, but that will > only be needed to be done once for the entire RXTX user > community if you use their stock release or once per new > release of RXTX if you have a customised package > > As for the whole windows/linux 32/64 i386/i686 issue, as you > have already stated, these can be delt with by your installer/JWS > > Will > > Dr. Douglas Lyon wrote: > > Hi Will, > > Thank you for your prompt response. > > > > It is not always possible to build Fat binaries. > > Normally, we would like to have a convention for the PPC vs > the i386 > > binary. What will we do when we compile for i686? > > > > From the historical perspective of the JNI programmer, the primary > > ARCH indicator has been the library name or library location. > > > > This is because: > > System.mapLibraryName(s); > > > > Provides for a native library name that maps for the > particular system. > > When loading a shared library, JVM calls mapLibraryName(libName) to > > convert libName to a platform specific name. On UNIX systems, this > > call might return a file name with the wrong extension (for > example, > > libName.so rather than libName.a). > > > > There are two solutions to this problem; Unique File Names > or Unique > > File Locations. > > > > Unique File Names (every arch has a unique filename): > > It has been proposed that we arrive at a standard file name for the > > arch, this would ease the identification of the correct, optimized > > binary. > > > > Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", > > mapLibraryName = "libNAME.so" > > Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = > > "libNAME.so" > > iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = > > "libNAME.jnilib" > > Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", > > mapLibraryName = "NAME.dll" > > Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", > > mapLibraryName = "libNAME.so" > > > > you will notice that Linux 32/64 and Solaris all use > "libNAME.so"... > > despite the architecture they are running on! > > Alternate names: > > G4: "libNAME.jnilib" > > Mac x386: "libNAME-x86.jnilib" > > Linux (i686): "name-linux-x86" > > Linux (Intel/AMD 64): "name-linux-x86_64" > > Linux (sparc): "name-linux-sparc" > > Linux (PPC 32 bit): "name-linux-ppc" > > Linux (PPC 64 bit): "name-linux-ppc_64" > > Windows XP/Vista (i686): "name-windows-x86" > > Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" > > Sun Solaris (Blade): "name-sun-sparc" > > Sun Solaris (Intel 64 bit): "name-sun-x86_64" > > > > Solution 2: Directory Names (each architecture lives in a specific > > location). > > > > Basically, an invocation to System.load will have to be > sanitized to > > make use of the architecture-based naming convention, or we can > > over-write the system.library.path at run time with a class-path > > byte-code hack. > > public static void pathHack() throws NoSuchFieldException, > > IllegalAccessException { > > Class loaderClass = ClassLoader.class; > > Field userPaths = loaderClass.getDeclaredField("sys_paths"); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > userPaths.setAccessible(true); > > userPaths.set(null, null); > > } > > Making the userPaths alterable at runtime will enable > modification of > > the system.library.path. Then you can append a native path that is > > architecture > > specific: > > public static void appendJavaLibraryPath(File path) { > > if (path.isFile()) In.message("warning: > appendJavaLibraryPath:" + > > "only directories are findable:" + path); > > System.out.println("appending:" + path + " to > > java.library.path"); > > try { > > pathHack(); > > } catch (NoSuchFieldException e) { > > e.printStackTrace(); > > > > } catch (IllegalAccessException e) { > > e.printStackTrace(); > > > > } > > String javaLibraryPath = "java.library.path"; > > String newDirs = System.getProperty(javaLibraryPath) + > > File.pathSeparatorChar + path; > > System.setProperty(javaLibraryPath, newDirs); > > System.out.println("java.library.path:" + > > System.getProperty(javaLibraryPath)); > > } > > This is otherwise not generally accessible. > > > > The system.load obviates the need to hack the java library path, we > > just write our own native loader and make sure no one else called > > system.loadLibrary. > > > > From the webstart programmer point of view, the arch is > used to direct > > the location search of a native resource; Thus: > > > > > > > > > > > > > > > download="eager"/> > > > > > > > > download="lazy" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, if we created a signed native library that can be beamed over. > > We use the same name for all (native.jar) and just change > the path as > > an architecture-based dispatch. That seems cleaner, to me...but > > perhaps it is a matter of taste. > > > > What do you think of that? > > > > Thanks! > > - Doug > > > >> Dr. Douglas Lyon wrote: > >>> Hi All, > >>> I have two kinds of libraries on the mac. One is PPC, the > other is > >>> i386. > >>> > >>> Both have the same name. However, they are of different type. > >>> For example: > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle i386 > >>> > >>> Vs. > >>> file librxtxSerial.jnilib > >>> librxtxSerial.jnilib: Mach-O bundle ppc > >>> > >>> > >>> During the java.library.path search done during the > native library > >>> linking phase, it is important for the loader to load the correct > >>> native libraries, or a run-time error occurs. > >>> > >>> Since the two libraries have IDENTICAL names, it is impossible to > >>> tell which is which, based on name alone. > >>> > >>> Is there a portable 100% > >>> Java way to determine arch of the binaries in a native library? > >>> > >>> Thanks! > >>> - Doug > >>> > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> This is why you need a universal binary, see list archives > >> > >> -- > >> Will Tatam > >> Systems Architect > >> Red61 > >> > >> 0845 867 2203 ext 103 > > > > > -- > Will Tatam > Systems Architect > Red61 > > 0845 867 2203 ext 103 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Tue Jan 8 02:27:25 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 04:27:25 -0500 Subject: [Rxtx] port initialization Message-ID: Hi All, I have been tempted not to call RXTXCommDriver.initialize() multiple times. However, I am concerned that the port status may change during the life of the program. I note that initialize is public. Is it our intention that people call initialize multiple times during the life of our applications in order to detect changes in port status? I define a change in port status as the addition or removal of a serial port. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 05:43:46 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 07:43:46 -0500 Subject: [Rxtx] port initialization In-Reply-To: References: Message-ID: <47837002.2040704@gatworks.com> > detect changes in port status? > > I define a change in port status as the addition or removal of a serial port. Does that port status also include disappearing, and reappearing? From lyon at docjava.com Tue Jan 8 06:12:35 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:12:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx Message-ID: Hi All, Please excuse the long e-mail. Regarding the use of multiple binaries for different native method platforms....and, in particular, the PPC vs Intel macs. I need to manage which native libraries I load, as I have several available under development for any given platform. The selection of the native library file is done at run-time and the location of the file needs to be remembered. The programs that I deploy also must work as webstart applications as well as development apps on the desk-top. Debugged native libraries need to be packed into signed jar files. I have a solution, which is not optimal. The development is at a cross-roads and I invite feedback and comments. In my development on a mac, I typically modify the PPC version of code without modifying the i386 version. Further: It is not always possible to build Fat binaries. Normally, we would like to have a convention for the PPC vs the i386 binary. And What will we do when we compile for i686? From the historical perspective of the JNI programmer, the primary ARCH indicator has been the library name or library location. This is because: System.mapLibraryName(s); Provides for a native library name that maps for the particular system. When loading a shared library, JVM calls mapLibraryName(libName) to convert libName to a platform specific name. On UNIX systems, this call might return a file name with the wrong extension (for example, libName.so rather than libName.a). There are two solutions to this problem; Unique File Names or Unique File Locations. Unique File Names (every arch has a unique filename): It has been proposed that we arrive at a standard file name for the arch, this would ease the identification of the correct, optimized binary. Linux 64 bit Pentium M: os.name = "Linux", os.arch = "amd64", mapLibraryName = "libNAME.so" Linux 32 bit: os.name = "Linux", os.arch = "i386", mapLibraryName = "libNAME.so" iBook G4: os.name = "Mac OS X", os.arch = "ppc", mapLibraryName = "libNAME.jnilib" Windows XP 32 bit: os.name = "Windows XP", os.arch = "x86", mapLibraryName = "NAME.dll" Sun Blade 1500 (64 bit): os.name = "SunOS", os.arch = "sparc", mapLibraryName = "libNAME.so" Linux 32/64 and Solaris all use "libNAME.so"... (as pointed out by: http://forum.java.sun.com/thread.jspa?threadID=5171496&messageID=9672435 ) No matter the architecture... Alternate names: G4: "libNAME.jnilib" Mac x386: "libNAME-x86.jnilib" Linux (i686): "name-linux-x86" Linux (Intel/AMD 64): "name-linux-x86_64" Linux (sparc): "name-linux-sparc" Linux (PPC 32 bit): "name-linux-ppc" Linux (PPC 64 bit): "name-linux-ppc_64" Windows XP/Vista (i686): "name-windows-x86" Windows XP/Vista (Intel/AMD 64): "name-windows-x86_64" Sun Solaris (Blade): "name-sun-sparc" Sun Solaris (Intel 64 bit): "name-sun-x86_64" Solution 2: Directory Names (each architecture lives in a specific location). Basically, an invocation to System.load will have to be sanitized to make use of the architecture-based naming convention, or we can over-write the system.library.path at run time with a class-path byte-code hack. public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } Making the userPaths alterable at runtime will enable modification of the system.library.path. Then you can append a native path that is architecture specific: public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } This is otherwise not generally accessible. The system.load obviates the need to hack the java library path, we just write our own native loader and make sure no one else called system.loadLibrary. From the webstart programmer point of view, the arch is used to direct the location search of a native resource; Thus: Note the ad-hoc nature of the directory organization. This is not good...and needs to be fixed. A better organization might be libs/rxtx/os/arch/native.jar Creating a toy-box cross-compilation technique for doing this on multiple platforms is, as I understand it, not easy. And then there is the problem of signing (or resigning) the jars (which is beyond the scope of this e-mail). So, if we created a signed native library that can be beamed over. We use the same name for all (native.jar) and just change the path as an architecture-based dispatch. That seems cleaner, to me...but perhaps it is a matter of taste. The selection of which Jar is typically ad-hoc in a beam-over implementation. Here is my thought on an implementation: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getCommDriver() { if (driver != null) return driver; final String libName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } fixDriver(); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } NativeLibraryBean nlb = NativeLibraryBean.restore(libName); if (nlb == null) { In.message("NativeLibraryBean cannot restore!"); if (In.getBoolean("do you have the " + libName + " library?")) { NativeLibraryManager.promptUserToLocateLibrary(libName); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } } if (nlb != null && nlb.isComesFromFile()) { NativeLibraryManager.appendJavaLibraryPath(nlb.getFile()); if (NativeLibraryManager.isLibLoadable(libName)) { return getDriver(); } } In.message("ER! SafeCommDriver could not load rxtxSerial."); return driver; } private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), "rxtxSerial"); } catch (IOException e) { e.printStackTrace(); } } //the following show what happens when you use ad-hoc methods to organize // the code... public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isPPCMac()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isIntelMac()) return new URL(rxtxUrl + "mac/intel_native/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); In.message("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } public class NativeLibraryManager { NativeLibraryBean nlb = null; public NativeLibraryManager(NativeLibraryBean nlb) { this.nlb = nlb; } public static void main(String[] args) { String libraryName = "rxtxSerial"; if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("loaded:"+libraryName+" in path"); return; } System.out.println("System.loadLibrary Could not load Library:"+libraryName); if (isLibLoadableViaBean(libraryName)){ System.out.println("loaded:"+libraryName+" with bean"); return; } System.out.println("isLibLoadableViaBean is false..."); } private static boolean isLibLoadableViaBean(String libraryName) { try { NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } public static void reportLibNotFindableAndDie(String libraryName) { System.out.println("Lib not in path:" + libraryName); System.exit(0); } public static void appendPath(String pathname) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException { Class clsLoader = ClassLoader.class; Field field = clsLoader.getDeclaredField("sys_paths"); String libPath = System.getProperty("java.library.path"); if (!field.isAccessible()) { field.setAccessible(true); } // // Reset the sys_paths field in the class loader to null so that // whenever "System.loadLibrary" is called it will be reconstructed // with the changed value. // field.set(clsLoader, null); if (!libPath.endsWith(System.getProperty("path.separator"))) { libPath = libPath.concat(System.getProperty("path.separator")); } System.setProperty("java.library.path", libPath.concat(pathname)); } public static void loadRxtx() { try { NativeLibraryManager.loadLibrary("rxtxSerial"); } catch (IOException e) { e.printStackTrace(); In.message("NativeLibraryManager ER!:LoadRxtx Failed"); } } public static void loadLibrary(String libraryName) throws IOException { System.out.println("loadLibrary...." + libraryName); appendNativeLibraryDirectory(); if (NativeLibraryManager.isLibLoadable(libraryName)) { System.out.println("library already in path"); return; } System.out.println("\nLib not in path:" + libraryName); NativeLibraryBean nlb = NativeLibraryBean.restore(libraryName); System.out.println("\nNativeLibraryBean:" + nlb); if (nlb == null) nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); nlb.save(); NativeLibraryManager nlm = new NativeLibraryManager(nlb); nlm.loadLibrary(); System.out.println("libraryLoaded"); } public void loadLibrary() throws IOException { final String libraryName = nlb.getLibraryName(); if (!NativeLibraryManager.isLibLoadable(libraryName)) fixDriver(libraryName); System.out.println("libraryName:"+libraryName); try { System.loadLibrary(libraryName); } catch (UnsatisfiedLinkError e) { System.out.println("NativeLibraryManager cannot load lib:" + libraryName + "\n trying from url resource"); nlb = new NativeLibraryBean(SafeCommDriver.getResourceUrl(), libraryName); if (In.getBoolean("want to locate the library:" + libraryName)) { promptUserToLocateLibrary(libraryName); loadLibrary(); } } } private void fixDriver(String libraryName) throws IOException { if (nlb.isComesFromUrl()) fixDriver(nlb.getUrl(), libraryName); else if (nlb.isComesFromFile()) { appendJavaLibraryPath(nlb.getFile()); } else System.out.println("ER:fixDriver " + libraryName + " did not load"); } public static String getLibraryPath() { return System.getProperty("java.library.path"); } public static String[] getLibraryPaths() { String s = getLibraryPath(); StringTokenizer st = new StringTokenizer(s, SystemUtils.getPathSeparator()); int n = st.countTokens(); String paths[] = new String[n]; for (int i = 0; i < n; i++) paths[i] = st.nextToken(); return paths; } public static void pathHack() throws NoSuchFieldException, IllegalAccessException { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } public static String mapLibraryName(String s) { return System.mapLibraryName(s); } public static void printLibraryPaths() { print(getLibraryPaths()); } public static void print(String libraryPaths[]) { for (int i = 0; i < libraryPaths.length; i++) System.out.println(libraryPaths[i]); } public static String getPathToLib(String libName) { NativeLibDetect nld = new NativeLibDetect(libName); return nld.getLibLocation(); } public static void testMapLibName() { System.out.println("rxtxSerial maps to:" + mapLibraryName("rxtxSerial")); } public static NativeLibraryBean getNativeLibraryBeanFromFile(String libraryName) { File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); return new NativeLibraryBean(nativeLibFile, libraryName); } public static void promptUserToLocateLibrary(String libraryName) { try { if (NativeLibraryManager.isLibLoadable(libraryName)) return; File nativeLibFile = Futil.getReadFile("please locate:" + mapLibraryName(libraryName)); appendJavaLibraryPath(nativeLibFile.getParentFile()); //System.out.println("lib in path?:"+NativeLibDetect.isLibInPath(libraryName)); //System.out.println("path is set, trying a System.loadLibrary:"); //System.loadLibrary("rxtxSerial"); //System.out.println("done"); NativeLibraryBean nativeLibraryBean = new NativeLibraryBean(nativeLibFile.getParentFile(), libraryName); nativeLibraryBean.save(); } catch (Exception e) { e.printStackTrace(); } } /** * Store all the native libraries in the * ~/.nativeLibrary directory * * @return a directory in the user home. Every user can have their own native lib. */ public static File getNativeLibraryDirectory() { File f = new File(SystemUtils.getUserHome() + SystemUtils.getDirectorySeparator() + ".nativeLibrary"); if (f.exists() && f.canWrite()) return f; try { if (f.mkdir()) return f; } catch (Exception e) { emitWritePermissionError(f); e.printStackTrace(); } return f; } private static void emitWritePermissionError(File f) { In.message("ER:Could not create:" + f + "please check write permission."); } public static File getNativeLibraryFile(String nativeLibraryName) { return new File(getNativeLibraryDirectory(), mapLibraryName(nativeLibraryName)); } /** * Append directories to the path if you want System.loadlib to find it. * * @param path */ public static void appendJavaLibraryPath(File path) { if (path.isFile()) In.message("warning: appendJavaLibraryPath:" + "only directories are findable:" + path); System.out.println("appending:" + path + " to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparatorChar + path; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:" + System.getProperty(javaLibraryPath)); } public static void fixDriver(URL resourceUrl, String nativeLibraryName) throws IOException { appendNativeLibraryDirectory(); if (isItTimeToBeamOverTheLibrary(nativeLibraryName, resourceUrl)) { beamOverLibrary(nativeLibraryName, resourceUrl); } } public static boolean isItTimeToBeamOverTheLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { return !NativeLibraryManager.isLibLoadable(nativeLibraryName) || !SystemUtils.isDateGood(getNativeLibraryFile(nativeLibraryName), resourceUrl); } private static void beamOverLibrary(String nativeLibraryName, URL resourceUrl) throws IOException { String mappedNativeLibraryName = mapLibraryName(nativeLibraryName); File tmpDir = new File( JDKBean.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); UrlUtils.getUrl(resourceUrl, tmpDir); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(mappedNativeLibraryName); if (b == null) throw new IOException("could not get:" + mappedNativeLibraryName); Futil.writeBytes(getNativeLibraryFile(nativeLibraryName), b); } /** * Append the native library directory to the java.library.path, * using my byte code hack. */ public static void appendNativeLibraryDirectory() { appendJavaLibraryPath(getNativeLibraryDirectory()); } /** * Test to see if you can load this library * * @param libName to load * @return true if loadable and loaded */ public static boolean isLibLoadable(String libName) { try { System.loadLibrary(libName); return true; } catch (UnsatisfiedLinkError e) { System.out.println("isLoadable: NativeLibraryManager UnsatisfiedLinkError:"); return false; } catch (Exception e) { System.out.println("isLoadable: NativeLibraryManager Exception:"); e.printStackTrace(); } Throwable thrown; try { if (OsUtils.isLinux()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for linux"); return true; } else if (OsUtils.isMacOs()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for osx"); return true; } else if (OsUtils.isWindows()) { System.loadLibrary(libName); PrintUtils.info("loaded " + libName + " for windows"); return true; } else { PrintUtils.info(libName + " not automatically provided for this OS."); return false; } } catch (Exception e) { thrown = e; } catch (UnsatisfiedLinkError e) { thrown = e; } PrintUtils.throwing("Utils", "Error:load" + libName, thrown); return false; } } public class NativeLibraryBean implements Serializable { private String key = null; private URL url = null; private File file = null; private String libraryName = null; public String toString(){ return "url:"+url+ "\nfile:"+file+ "\nlibraryName:"+libraryName+ "\nkey:"+key; } public void save(){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); pu.save(this); } ?? /** * * @return null if error on restore. */ public static NativeLibraryBean restore(String libraryName){ PreferencesUtils pu = new PreferencesUtils(getKey(libraryName)); return (NativeLibraryBean)pu.restore(); } public NativeLibraryBean(URL url,String libraryName){ this.url = url; initLibrary(libraryName); } private void initLibrary(String libraryName) { this.libraryName = libraryName; this.key = getKey(libraryName); } private static String getKey(String libraryName) { return "NativeLibraryBean" + libraryName; } public NativeLibraryBean(File file, String libraryName){ this.file = file; initLibrary(libraryName); } public boolean isComesFromFile() { return file !=null; } public boolean isComesFromUrl() { return url!=null; } public String getLibraryName() { return libraryName; } public URL getUrl() { return url; } public File getFile() { return file; } } File locations are stored in the users Root Preferences...so that they may persist from one run to the next. If we really want to do it up right, I think that the osName/Arch organization might be good... Some OsNames/arch names might be available somewhere...I found this: http://lopica.sourceforge.net/os.html I am not sure how to get a list of all the values for: os.name? Operating system name and os.arch Operating system architecture Does anyone know this? Is a multi-platform toybox build available for general use? I would think that a giant build/sign and deploy mechanism might be the way to go. Has someone already done this? Thanks! - Doug From lyon at docjava.com Tue Jan 8 06:52:30 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 08 Jan 2008 08:52:30 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: Hi All, I decided that the only pure java way to identify the libraries is to make use of a stream sniffer (as described in my book, Image Processing in Java)...basically, you use magic numbers at the beginning of the file...The following works well: if (match(254,237,250,206)) return PPC; if (match(206,250,237,254)) return I386; The goal is to make sure that the library you plan to load matches with the arch that you are loading on. This is pretty much how the "file" command works, in unix, except that it ignores the file suffix. The file suffix is not reliable...in general. If someone has a better idea, I would love to hear it. Thanks! - Doug From netbeans at gatworks.com Tue Jan 8 08:11:19 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 10:11:19 -0500 Subject: [Rxtx] identification of libraries In-Reply-To: References: Message-ID: <47839297.2030301@gatworks.com> > > If someone has a better idea, I would love to hear it. I suppose getting the sys admin to *not* install the errant libraries? It really should not be a function of java to figure out if shared libs are 'good'. There is a 'sorta' underlying presumption that the executables, as well as shared libs, will conform to the native (ARCH) system standards. for unix there would be a symbolic link ie. libName.so --> libName.unix.ppc.2.7r2.so If the mac has the concept of symbolic link names, then the install process has to figure out the ARCH, and do appropriate symbolic linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> libName.Mac.i386.2.7r2.so I suppose if the shared library manager barfs, and user is confused, than maybe the magic code will assist in figuring whats wrong. From gergg at cox.net Tue Jan 8 10:01:51 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 11:01:51 -0600 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster? In-Reply-To: <380-22008165151820890@earthlink.net> References: <380-22008165151820890@earthlink.net> Message-ID: <4783AC7F.5060605@cox.net> James Brannan wrote: > Okay, maybe I'm being too sensitive... > > Given that you say the events are pretty much confined to this dll, I'll > take a look at it on Linux, see what's going on. I'll break out my C/C++ > books gathering dust somewhere. Chances are though, I'll just make a mess > of things, I'm a j2ee programmer after all - i.e. if there ain't an API for > it, then it can't be done ;-) > > BTW, I just priced out the cost of serialPort to the consumer, 99 cents, > but I'd still much rather use opensource for this part of the application. Hi James. I think you mistook the response as a negative rather than an invitation to provide a way for the developers to solve your problem. He simply asked for a test case/environment where he could reproduce your issue to better understand what was actually happening. Free software means that noone has a commitment to fix anything for your, except yourself. If you can't do it yourself, then it only makes since that you need to take the steps that would enable someone else to solve it for you. That might mean spending time to help developers of a package understand the problem. It might also mean that you spend money to try something else. The operating system you are using, windows, is not a realtime operating system. This means that there are never going to be any guarantees about what piece of software is doing what at any particular moment. The OS simply doesn't decide what takes priority to execute next except through the use of priorities. I.e. there are no wall clock controls on what is running, and even then, the OS and the Java garbage collector can cause pauses because either may lock down access to some things that another thread/task needs. The java Thread class has a setPriority() method that you can use with Thread.currentThread().setPriority(...); to change the priority of the current thread. If you are printing out all kinds of debugging stuff, that will take 100s of millis out of the time of the inner most loop on a timesharing, non-realtime system. So, don't use debugging in the inner loop when you are trying to see how fast something will go. Additionally, code such as Logger log = Logger.getLogger( getClass().getName() ); ... while( ... ) { log.fine( "doing something with "+somevar+ ", to get "+someother ); ... } still wastes a lot of time constructing strings that are never used. So, always include if( log.isLoggable( Level.FINE ) ) on such logging statements to avoid creating extra String garbage that will then have to be cleaned up. Realistically, I don't think it is a great idea to try and do what you are doing on a timesharing operating system. It may work, mostly, but again, you will likely see lost events because of the operating systems ability to arbitrarily stop processing on any executing task for countless reasons which you can not control. If the input stream from the device was buffered in some way (e.g. it was a serial stream, not toggled control lines), then you might have a better chance. You might consider putting together a small PIC based board which can watch your toggling control leads and then send out bytes on a serial stream which the OS will buffer quite successfully for you to then process in the code running on the PC. Gregg Wonderly From gergg at cox.net Tue Jan 8 11:23:10 2008 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 08 Jan 2008 12:23:10 -0600 Subject: [Rxtx] identification of libraries In-Reply-To: <47839297.2030301@gatworks.com> References: <47839297.2030301@gatworks.com> Message-ID: <4783BF8E.80803@cox.net> U. George wrote: >> If someone has a better idea, I would love to hear it. > > I suppose getting the sys admin to *not* install the errant libraries? > It really should not be a function of java to figure out if shared libs > are 'good'. There is a 'sorta' underlying presumption that the > executables, as well as shared libs, will conform to the native (ARCH) > system standards. > for unix there would be a symbolic link ie. libName.so --> > libName.unix.ppc.2.7r2.so > If the mac has the concept of symbolic link names, then the install > process has to figure out the ARCH, and do appropriate symbolic > linkages. ie libName.so --> libName.Mac.ppc.2.7r2.so -OR- libName.so --> > libName.Mac.i386.2.7r2.so > > I suppose if the shared library manager barfs, and user is confused, > than maybe the magic code will assist in figuring whats wrong. I manage this though the use a resource in the build of the jar to designate which library to load for which platform. You can then decide what the resource keys are by putting a map into that resource to get from key to library. The nice thing is that to fix a missing key, you just create a new jar with a revised resource that contains the needed mapping and put the old jar in the class-path: list. Thus, anyone can "add" support for a key that should would with an existing library without having to write code. Gregg Wonderly From rspencer at FuelQuest.com Tue Jan 8 13:04:59 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 14:04:59 -0600 Subject: [Rxtx] Dual Core Problem Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> What has been the resolve in this issue? Can someone reply back with the patches that may work? I have a dual-core / hyper-threaded Linux i686 OS that ... well just won't allow me to close the SerialPort, In and Out stream objects. I believe this may be the cause. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0021.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image001.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/60b6fd90/attachment-0021.jpe From netbeans at gatworks.com Tue Jan 8 13:56:03 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 15:56:03 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> Message-ID: <4783E363.2060700@gatworks.com> thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From rspencer at FuelQuest.com Tue Jan 8 14:09:17 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Tue, 8 Jan 2008 15:09:17 -0600 Subject: [Rxtx] Dual Core Problem References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Sorry, This may be a stupid question, where are the patches? On the mailing list I can only see the mail-threads. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: U. George [mailto:qmail at gatworks.com] Sent: Tuesday, January 08, 2008 2:53 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? From netbeans at gatworks.com Tue Jan 8 14:17:44 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 16:17:44 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E2A4.4000502@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702CEA3AE@fqmx03.fuelquest.com> Message-ID: <4783E878.5010507@gatworks.com> I post mine on the mail list. I think the same for the other camp, which is clearly wrong! :)) Spencer, Rodney wrote: > Sorry, > This may be a stupid question, where are the patches? On the mailing > list I can only see the mail-threads. > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: U. George [mailto:qmail at gatworks.com] > Sent: Tuesday, January 08, 2008 2:53 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Tue Jan 8 14:42:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 14:42:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: I ment to post this Friday but didnt have the files. We did a little testing to compare the two patches. http://www.qbang.org/cpu/ Georges patch should be the profile on the left in each jpg. It appears to use about the same amount of CPU but distributes the work between the CPUs. The 'completely thread safe' class tends to work one CPU more. Georges patch completed the tests slightly faster. This is a test that exercises the serial port via a loopback connection. Its 4 min of heavy open/close/read/write. The graphs show combined cpu use or cpu use per core. The tests are run on two identical machines via vnc. The filenames tell you if it is per core or combined use thats graphed. On Tue, 8 Jan 2008, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: >> What has been the resolve in this issue? Can someone reply back with >> the patches that may work? > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Tue Jan 8 15:12:54 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 17:12:54 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: <4783F566.3030803@gatworks.com> What seems interesting is that 'wall clock' appears the same. Although the 2nd cpu ( if i see it right ) appears under a constant load, and not as erratic as the first cpu. Somewhere the wall-clock should have been reduced by the work done by the 2nd cpu. a little bit of a mystery. Trent Jarvi wrote: > > I ment to post this Friday but didnt have the files. We did a little > testing to compare the two patches. > > http://www.qbang.org/cpu/ > From beat.arnet at gmail.com Tue Jan 8 15:55:06 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 8 Jan 2008 17:55:06 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783E363.2060700@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> Message-ID: The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: > thus far nothing. But either patch will work. > My patch forces the user to coordinate the sequence of their I/O > operations ( ie removal of IOLocked, synchronized reads, and a > synchronized closed ) . > The other set of patches synchronizes *all* access to IOLocked. you pay > with the extra overhead that each synchronize() costs. > > Spencer, Rodney wrote: > > What has been the resolve in this issue? Can someone reply back with > > the patches that may work? > > _______________________________________________ > 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/20080108/17dddf01/attachment-0021.html From tjarvi at qbang.org Tue Jan 8 16:39:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Jan 2008 16:39:06 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <4783F566.3030803@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: It may not be easy to spot but the wallclock for your patch was 221 seconds vs 233 for second patch. There is significant overhead for the application and test infrastructure also. 10 seconds is a big difference. On Tue, 8 Jan 2008, U. George wrote: > What seems interesting is that 'wall clock' appears the same. Although the > 2nd cpu ( if i see it right ) appears under a constant load, and not as > erratic as the first cpu. Somewhere the wall-clock should have been reduced > by the work done by the 2nd cpu. a little bit of a mystery. > > Trent Jarvi wrote: >> >> I ment to post this Friday but didnt have the files. We did a little >> testing to compare the two patches. >> >> http://www.qbang.org/cpu/ >> > From netbeans at gatworks.com Tue Jan 8 16:48:26 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 18:48:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47840BCA.7050801@gatworks.com> Now imagine reading a byte at a time, or writing a byte a time. Anyway, i'll see if I can create a threadsafe InputStream, and output stream that will keep the timid sleeping at nights. Threadsafe almost appears to imply that those folks should be runnable on one-cpu ( of which some multi-cpu OS's allow ) systems. Trent Jarvi wrote: > > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. > > On Tue, 8 Jan 2008, U. George wrote: > >> What seems interesting is that 'wall clock' appears the same. Although >> the 2nd cpu ( if i see it right ) appears under a constant load, and >> not as erratic as the first cpu. Somewhere the wall-clock should have >> been reduced by the work done by the 2nd cpu. a little bit of a mystery. >> >> Trent Jarvi wrote: >>> >>> I ment to post this Friday but didnt have the files. We did a little >>> testing to compare the two patches. >>> >>> http://www.qbang.org/cpu/ >>> >> > > From netbeans at gatworks.com Tue Jan 8 19:04:05 2008 From: netbeans at gatworks.com (U. George) Date: Tue, 08 Jan 2008 21:04:05 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47840BCA.7050801@gatworks.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> <47840BCA.7050801@gatworks.com> Message-ID: <47842B95.5060007@gatworks.com> > Anyway, i'll see if I can create a threadsafe InputStream, and output > stream that will keep the timid sleeping at nights. I think these 2 classes will keep the threadsafe people happy. Then maybe not. ;-/ Anyway, Usage: java.io.InputStream in = new ThreadSafeRXTXInputStream( commport.getInputStream() ); -- AND -- java.io.OutputStream out = new ThreadSafeRXTXOutputStream( commport.getOutputStream() ); -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXInputStream.java Type: text/x-java Size: 1639 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0042.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadSafeRXTXOutputStream.java Type: text/x-java Size: 1064 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080108/3c11981d/attachment-0043.bin From Martin.Oberhuber at windriver.com Wed Jan 9 06:35:10 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 9 Jan 2008 14:35:10 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Hi all, in general it is discouraged to call out to a lot of (partially unknown) code from "inside" a synchronized block. When I'm getting you right that's what you are suggesting, both with the SerialPortManager and the RXTXThreadSafe*Stream approaches. Such a construct is referred to as "open call" and prone to deadlock, because the unknown called code may have callbacks (e.g. due to events) to other parts of the application. If those event listeners make a thread switch (e.g. Display.syncExec()) and that other thread requires a reasource that's currently waiting in the synchronized...block you're deadlocked. It may sound unlikely and academic, but we've seen exactly such deadlocks a lot. Therefore I'm much in favor of keeping the synchronized blocks small, and inside RXTX only. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, January 08, 2008 11:55 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem The other option is to leave rxtxt untouched and make all accesses to rxtx from synchronized statements. I created a SerialPortManager class for this purpose and have not experienced any deadlocks since. Beat On Jan 8, 2008 3:56 PM, U. George wrote: thus far nothing. But either patch will work. My patch forces the user to coordinate the sequence of their I/O operations ( ie removal of IOLocked, synchronized reads, and a synchronized closed ) . The other set of patches synchronizes *all* access to IOLocked. you pay with the extra overhead that each synchronize() costs. Spencer, Rodney wrote: > What has been the resolve in this issue? Can someone reply back with > the patches that may work? _______________________________________________ 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/20080109/fe2caeed/attachment-0021.html From netbeans at gatworks.com Wed Jan 9 07:14:49 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 09:14:49 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com><4783E363.2060700@gatworks.com> <460801A4097E3D4CA04CC64EE648584804170399@ism-mail03.corp.ad.wrs.com> Message-ID: <4784D6D9.9080101@gatworks.com> Oberhuber, Martin wrote: > Hi all, > I'm getting you right that's what you are suggesting, both > with the SerialPortManager and the RXTXThreadSafe*Stream > approaches. Nothing to to with Serial Port Manager, whatever that is. It has something to do with with InputStream & OutputStream. > > Such a construct is referred to as "open call" and prone to > deadlock, because the unknown called code may have > callbacks (e.g. due to events) to other parts of the application. > If those event listeners make a thread switch (e.g. Display.syncExec()) > and that other thread requires a reasource that's currently > waiting in the synchronized...block you're deadlocked. Gee, thats nice, but what that got to do with what is proposed. I think u need to focus more on what the issues are, and what the solutions might be. InputStream and OutputStream do not throw events. They do throw exceptions. Those exceptions are not caught or handled by RXTX ( my proposal ) . They are passed back to the user program, and thus removing the synchronize'd lock along the way. > > It may sound unlikely and academic, but we've seen > exactly such deadlocks a lot. Therefore I'm much in > favor of keeping the synchronized blocks small, > and inside RXTX only. I'm more in favor of removing them all at that I/O level. If you really-really need synchronization, do it at a higher level. From ajmas at sympatico.ca Wed Jan 9 07:27:37 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 09:27:37 -0500 Subject: [Rxtx] binary build type In-Reply-To: References: Message-ID: <1E3B29FE-6EB1-4046-AE46-8B033ABC5BBD@sympatico.ca> On 7-Jan-08, at 08:31 , Dr. Douglas Lyon wrote: > Hi All, > I have two kinds of libraries on the mac. One is PPC, the > other is i386. > > Both have the same name. However, they are of different type. > For example: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 > > Vs. > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle ppc Hi, There is a simpler solution, if you get the latest code from CVS, since support for creating universal binaries is now available (create Intel 32bit, 64bit and PPC 32bit). Just note that in order for universal binaries to be created you will need the 10.4 SDK: /Developer/SDKs/MacOSX10.4u.sdk You will need to run: autoconf ./configure make If you have any issues let us know. Andre From alfonso.benot.morell at gmail.com Wed Jan 9 11:28:46 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 19:28:46 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Dear All, I have been trying to work with the TwoWaySerialComm example as part of a project in NetBeans 6.0 but is going extremely slow...it takes ages to write the first character to the port and is incapable of ready anything. It even takes several seconds to stop the execution/debugging. Has someone experienced the same problem? What would you suggest me to get it running faster? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/0e02b14d/attachment-0020.html From netbeans at gatworks.com Wed Jan 9 12:16:10 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 14:16:10 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> Message-ID: <47851D7A.2030308@gatworks.com> dont debug. run the application. place time stamps before the read, and after the read. same for writes. print out the time difference between them. Alfonso Benot-Morell wrote: > Dear All, > > I have been trying to work with the TwoWaySerialComm example as part of > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > write the first character to the port and is incapable of ready > anything. It even takes several seconds to stop the execution/debugging. > > Has someone experienced the same problem? What would you suggest me to > get it running faster? > > Thank you very much for your help and your time. > > Kind regards. > > Alfonso Benot-Morell > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alfonso.benot.morell at gmail.com Wed Jan 9 12:30:04 2008 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 9 Jan 2008 20:30:04 +0100 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 In-Reply-To: <47851D7A.2030308@gatworks.com> References: <7828521c0801091028s163431d7m7b759728d89a43cc@mail.gmail.com> <47851D7A.2030308@gatworks.com> Message-ID: <7828521c0801091130ia1323f9hd85d031b7bd6aade@mail.gmail.com> The debugging was trying to find where it slowed down. It also runs slowly. For example, when I write some commands to be sent through the serial port it takes minutes...and even longer to read the responses from the device (if able to do so). Would that work in this situation? Many thanks. On Jan 9, 2008 8:16 PM, U. George wrote: > dont debug. run the application. > place time stamps before the read, and after the read. > same for writes. > print out the time difference between them. > > > > Alfonso Benot-Morell wrote: > > Dear All, > > > > I have been trying to work with the TwoWaySerialComm example as part of > > a project in NetBeans 6.0 but is going extremely slow...it takes ages to > > write the first character to the port and is incapable of ready > > anything. It even takes several seconds to stop the > execution/debugging. > > > > Has someone experienced the same problem? What would you suggest me to > > get it running faster? > > > > Thank you very much for your help and your time. > > > > Kind regards. > > > > Alfonso Benot-Morell > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080109/1172fba2/attachment-0020.html From ajmas at sympatico.ca Wed Jan 9 13:53:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 9 Jan 2008 15:53:29 -0500 Subject: [Rxtx] TwoWaySerialComm example and NetBeans 6.0 Message-ID: <6buhm2$54nrks@toip7.srvr.bell.ca> From: "Alfonso Benot-Morell" wrote: > > The debugging was trying to find where it slowed down. It also runs slowly. > For example, when I write some commands to be sent through the serial port > it takes minutes...and even longer to read the responses from the device (if > able to do so). Would that work in this situation? > A few questions: - what platform are you running on? - what is your device? - how are you communicating with the device? - what is the cpu usage during this time? Andre From gregory.dupriez at gmail.com Wed Jan 9 13:58:03 2008 From: gregory.dupriez at gmail.com (Gregory Dupriez) Date: Wed, 9 Jan 2008 21:58:03 +0100 Subject: [Rxtx] Issue with RXTX library - Jvm crash In-Reply-To: References: <4777B72C.2040900@red61.com> Message-ID: Sorry to answer after a few times. I only have the time to test today. Test have been done on windows xp and 2000 with sun jvm 1.5, 1.6 and jrockit jvm with the same result. I am the same situation. The data sent to the parallel bytes has a length of n*8 bytes. Unfortunately, there's a long time that I didn't program in c++. I could not be very useful to make investigations to fix the issue. Thanks for your help. I know now how to avoid the issue. Greg. 2007/12/30, Trent Jarvi : > > On Sun, 30 Dec 2007, Will Tatam wrote: > > > See also > > > > http://mailman.qbang.org/pipermail/rxtx/2007-November/1813769.html > > > > Will > > > > Gregory Dupriez wrote: > >> Hi everybody, > >> > >> I currently have some issue with the RXTX library version 2.1-7r2. > >> When I try to send to send some data to my parallel port, jvm crashes. > >> But it doesn't happen all the time. It seems to be dependant on the > data. > >> > >> It seems to be the same issue that the one described on the mailing > >> list within this post > >> http://mailman.qbang.org/pipermail/rxtx/2005-April/1765742.html > >> > >> I've put the report of the jvm crash at the end of my mail. > >> > >> It's quite an old issue but if somobody has solved the problem, it > >> will help me a lot. > >> I already try with different versions of the rxtx library and > >> different versions of the jvm but with the same result. > >> > >> In advance, thanks for your help. > >> > >> Regards, > >> > >> Gregory Dupriez > >> > >> # > > > > > > Parallel support needs a cleanup. We have been taking patches and > including them but I do not know that this issue has been resolved. > > While looking at bugs like this, reproducability, sporatic nature, OS type > and version all help form a picture of the type of problem. > > I see in the past that we have had a case in which the crash was > reproducable by sending 8*N bytes. Is this reproducable for you in the > same fassion? > > I see a couple odd things in the parallel write I would not do today. > > jbyte *body = (*env)->GetByteArrayElements( env, jbarray, 0 ); > unsigned char *bytes = (unsigned char *)malloc( count ); > int i; > for( i = 0; i < count; i++ ) bytes[ i ] = body[ i + offset ]; > > > The memory is later free'd properly. We do not check that offset is sane. > We do not need to malloc. Just use the offset in the array and we can > dump the malloc/free plus eliminate a large number of copies. > > (void * ) ((char *) body + total + offset) > > The above is used in SerialImp.c writeArray to do that. > > The other is we never release the ByteArrayElements. This is done in > Serialimp.c writeArray also. > > (*env)->ReleaseByteArrayElements( env, jbarray, body, 0 ); > > I suspect there are many fixes like this that need to be done for the > ParallelImp.c. > > -- > Trent Jarvi > tjarvi at qbang.org > -- If you want a gmail mailbox (1Go), just send me a mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cbcb5f51/attachment-0020.html From gergg at cox.net Wed Jan 9 14:22:45 2008 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 09 Jan 2008 15:22:45 -0600 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <29EA34939634AE4D8C5CF241CC3D2B1702CEA339@fqmx03.fuelquest.com> <4783E363.2060700@gatworks.com> <4783F566.3030803@gatworks.com> Message-ID: <47853B25.20403@cox.net> Trent Jarvi wrote: > It may not be easy to spot but the wallclock for your patch was 221 > seconds vs 233 for second patch. There is significant overhead for the > application and test infrastructure also. 10 seconds is a big difference. It may be possible to remove this difference with some more study of the code. The use of AtomicLong for counting instead of synchronizing, would make it a mute point most likely. It might be easier to just remove the counter and force the application to manage the close issue directly. Gregg Wonderly From james.i.brannan at lmco.com Wed Jan 9 14:57:16 2008 From: james.i.brannan at lmco.com (Brannan, James I (N-Fenestra)) Date: Wed, 09 Jan 2008 16:57:16 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More Message-ID: I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/cf5ee89a/attachment-0020.html From tjarvi at qbang.org Wed Jan 9 15:28:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 15:28:15 -0700 (MST) Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: On Wed, 9 Jan 2008, Brannan, James I (N-Fenestra) wrote: > I downloaded the source code from the site and took a look at it > (rxtx-2.1-7r2.zip). > > I doubt the problems I'm seeing has to do with the platform being > Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, > in panic, after Trent suggested I might have problems with the Serial > Port/USB converter on the Mac, I tested that too on Windoz and it worked > just fine. Remember, this is bicycle speed, not a lunar launcher's > speed :-) when using Sun's CommAPI, I'm off, but no more off then most > bicycle computers I've tested against. The USB dongles are only a problem if their drivers are problematic. The problem is knowing which dongles have bad drivers. Usually, if you recognize the name, the driver is OK. Sometimes you will find USB serial dongles for next to nothing that may not even have a vendors name or address on the package. Pin status changes may not have been on their checklist before shipping. For the same reason, just because a dongle works on one OS, does not mean you will have the same level of functionality on another OS. -- Trent Jarvi tjarvi at qbang.org From rspencer at FuelQuest.com Wed Jan 9 16:07:08 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Wed, 9 Jan 2008 17:07:08 -0600 Subject: [Rxtx] Compiling in Windows Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> I'm having a tough time getting RXTX to compile in Window (DOS or CYGWIN) can anyone give some help on this? This is what I get using LCC: C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc C:\code\rxtx-devel\src>set CLASSPATH=. C:\code\rxtx-devel\src>rem set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin C:\code\rxtx-devel\src>set PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin C:\code\rxtx-devel\src>make -f ..\Makefile.lcc lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c cpp: init.c:6 Could not find include file 0 errors, 1 warning lcc -I\C:\tools\jdk1.6.0_03\include -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skipping `*' `,' `jclass' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefinition of 'JNICALL' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previous definition of 'JNICALL' here Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skipping `*' `,' `jobject' `,' `jstring' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skipping `*' `,' `jobject' `,' `jint' Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extraneous old-style parameter list Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no type specified. Defaulting to int Error c:\code\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too many errors make: *** [SerialImp.obj] Error 1 I have attached the Makefile.lcc too. Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0020.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1729 bytes Desc: image002.jpg Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0020.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.lcc Type: application/octet-stream Size: 1975 bytes Desc: Makefile.lcc Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080109/4fea66d8/attachment-0020.obj From netbeans at gatworks.com Wed Jan 9 17:01:07 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 09 Jan 2008 19:01:07 -0500 Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <47856043.6030001@gatworks.com> I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch Spencer, Rodney wrote: > I?m having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > From tjarvi at qbang.org Wed Jan 9 20:38:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 9 Jan 2008 20:38:27 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Thu Jan 10 00:05:52 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:05:52 -0500 Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: Hi All, When I look at the distros for the pre-built operating systems binaries: http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ freebsd is missing. Do I need to provide native libs for free-bsd/i386? Can I use the Linux/i386 for that? Thanks! - Doug From lyon at docjava.com Thu Jan 10 00:25:53 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 10 Jan 2008 02:25:53 -0500 Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: Hi All, I tried the fat binary build for the macosx in: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib And got the typical: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file. please see: How can I use Lock Files with rxtx? in INSTALL .... Are we still using lock files on the mac? I think the ToyBox has not been built for a while...March 2006? Thanks! - Doug From rspencer at FuelQuest.com Thu Jan 10 07:41:39 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 08:41:39 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <47856043.6030001@gatworks.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/d4fe408d/attachment-0019.html From rspencer at FuelQuest.com Thu Jan 10 08:15:41 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 09:15:41 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com><47856043.6030001@gatworks.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA8F16@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA8F62@fqmx03.fuelquest.com> This is what I'm getting when trying to do it the mingw32 way: C:\temp\rxtx\patched\build>set JAVA_HOME=C:\tools\jdk1.6.0_03 C:\temp\rxtx\patched\build>set CYGWIN_HOME=C:\cygwin C:\temp\rxtx\patched\build>set MINGW_HOME=C:\tools\MinGW C:\temp\rxtx\patched\build>set LCC_HOME=C:\tools\lcc C:\temp\rxtx\patched\build>set CLASSPATH=. C:\temp\rxtx\patched\build>set PATH=%JAVA_HOME%\bin;%MINGW_HOME%\bin;%CYGWIN_HOME%\bin C:\temp\rxtx\patched\build>make Makefile:1: *** missing separator. Stop. I have attached the MakeFile I used. Please help with people are using to compile in Windows. ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Spencer, Rodney Sent: Thursday, January 10, 2008 8:42 AM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows Right, I fixed the error - the path needed double backslashes \\. It starts to compile but it has a compilation error: lcc -IC:\\tools\\jdk1.6.0_03\\include -IC:\\tools\\jdk1.6.0_03\\include\\win32 -I. termios.c cpp: c:\temp\rxtx\patched\src\win32termios.h:470 termios.c:75 Macro redefinition of EBADFD, previously defined in c:\tools\lcc\include\errno.h 91 Warning termios.c: 1081 Missing prototype for 'get_free_fd' Warning termios.c: 2054 Missing prototype for 'show_DCB' Error termios.c: 2665 redefinition of 'fstat' Error c:\tools\lcc\include\sys\stat.h: 65 Previous definition of 'fstat' here Warning termios.c: 2828 possible usage of result before definition 2 errors, 4 warnings make: *** [termios.obj] Error 1 How are people compiling this in Windows? I tried to use the mingw32 way and it failed and now I've been trying the lcc way and having the above error. I haven't changed anything in the C classes so I don't know what's going on. -----Original Message----- I suppose the first would be: cpp: c:\code\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could not find include file the C compiler could not find the java file "jni.h", which I suppose would be in the java/JDK ( and not jre ) direcories of whereever the JDK is installed. the PATH to the diretory for jni.h would be under the "-I" ( for include ) switch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0019.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 11638 bytes Desc: Makefile Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/c0f23606/attachment-0019.obj From tjarvi at qbang.org Thu Jan 10 08:44:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:44:21 -0700 (MST) Subject: [Rxtx] free bsd In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > > When I look at the distros for the pre-built operating systems binaries: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/FreeBSD/ > freebsd is missing. > > Do I need to provide native libs for free-bsd/i386? > Can I use the Linux/i386 for that? > FreeBSD does have a Linux compatability feature. I do not know anything about it though. Remember that the ToyBox is done as an abstract exercise in gcc capabilities. All of those libraries are from running one (ugly) build script on x86_64 Linux. I only tested that the libraries load and open a port on x86_64 Linux and 32 bit WinXP. People have had success with many other libraries found there but thats more luck than anything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 08:47:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 08:47:13 -0700 (MST) Subject: [Rxtx] are lock files still in use? In-Reply-To: References: Message-ID: On Thu, 10 Jan 2008, Dr. Douglas Lyon wrote: > Hi All, > I tried the fat binary build for the macosx in: > http://rxtx.qbang.org/ToyBox/2.1-7-build1/Mac_OS_X/i686-apple-darwin8/librxtxSerial.jnilib > And got the typical: > check_group_uucp(): error testing lock file creation Error > details:Permission deniedcheck_lock_status: No permission to create > lock file. > please see: How can I use Lock Files with rxtx? in INSTALL > .... > > Are we still using lock files on the mac? > > I think the ToyBox has not been built for a while...March 2006? > They are older. Yes. We will fire up the ToyBox again with the next release. What would you like to see from the ToyBox in the future? -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Thu Jan 10 09:45:52 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Thu, 10 Jan 2008 17:45:52 +0100 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Hi James, don't expect too much from Java Thread Priorities. All books about Java Threading that I've read discourage using Thread Priorities, and encourage using monitors (wait(), join(), notify() etc) instead. The point is that ideally, in a multi-threaded app only few threads should be runnable at any time and no thread should be wasting time by busy waiting. If only few threads are runnable, thread priorities really don't matter at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Brannan, James I (N-Fenestra) Sent: Wednesday, January 09, 2008 10:57 PM To: rxtx at qbang.org Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More I downloaded the source code from the site and took a look at it (rxtx-2.1-7r2.zip). I doubt the problems I'm seeing has to do with the platform being Windoze, again, Sun's CommAPI works just fine on the machine. Moreover, in panic, after Trent suggested I might have problems with the Serial Port/USB converter on the Mac, I tested that too on Windoz and it worked just fine. Remember, this is bicycle speed, not a lunar launcher's speed :-) when using Sun's CommAPI, I'm off, but no more off then most bicycle computers I've tested against. I'm assuming the code I was most interested in was that in RXTXPort.java, yes? Looking at it, it is pretty simple to see one big thing I think I can do, and a couple smaller things. Let me know if ya think this is a waste. 1) assign MAX_PRIORITY to the MonitorThread, throwing in a monThread.yield() in the sendEvent method at the top and then again right after I send the event to the listener. - My thoughts are that by setting the priority really high, it will take precedence over all other processing my Java program is doing....and I'm doing a lot....playing mp3's in a thread, running Mplayer in slave mode and monitoring it, running a timer, etc. Again, remember it's a bicycle computer, a second here or there lag, or being off is okay - provided its close enough to what the person has mounted on their handlebars ;-) 2) couple nitpicky things....in the sendEvent there's a case statement for sending debug info, that code, should be wrapped in a if(debug_event){ case statement }.... I went ahead and just removed all debugging statements, albeit, the cummulative effect of if(debug) checks is probably negligable.... Seems to me if this doesn't fix it then its at the native code layer. Yes? No? I'll post how it goes after I build the jar and test on my bicycle.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/fe1155ed/attachment-0019.html From netbeans at gatworks.com Thu Jan 10 10:26:24 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 12:26:24 -0500 Subject: [Rxtx] RXTX vs. Sun - Sun's Faster: More In-Reply-To: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848041D129D@ism-mail03.corp.ad.wrs.com> Message-ID: <47865540.9010408@gatworks.com> Oberhuber, Martin wrote: > Hi James, > > don't expect too much from Java Thread Priorities. All books about > Java Threading that I've read discourage using Thread Priorities, and > encourage using monitors (wait(), join(), notify() etc) instead. > For instance, I place background tasks, that can be placed at a lower priority, on a lower scheduling priority. As well as any other task that does not need immediate scheduling response. So: I'd encourage it. :} But then again, I dont read those books, and rather rely on the programmers who develop the strategy and coding to do these various things. From geraldonetto at gmail.com Thu Jan 10 10:57:49 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 15:57:49 -0200 Subject: [Rxtx] rs232 support? Message-ID: Hi Guys, how are you doing? Sorry for this newbie question, but i was not able to find out this information does rxtx supports rs232? if not, any suggestion? Kind Regards and Best wishes, Geraldo -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From netbeans at gatworks.com Thu Jan 10 11:08:26 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 10 Jan 2008 13:08:26 -0500 Subject: [Rxtx] rs232 support? In-Reply-To: References: Message-ID: <47865F1A.8040202@gatworks.com> Yes. BUT rs232 is an electrical specification used by the serial port of many many computers for many years. Geraldo Netto wrote: > Hi Guys, > > how are you doing? > > Sorry for this newbie question, > but i was not able to find out this information > > does rxtx supports rs232? > if not, any suggestion? > > Kind Regards and Best wishes, > > Geraldo From geraldonetto at gmail.com Thu Jan 10 11:10:45 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Thu, 10 Jan 2008 16:10:45 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <47865F1A.8040202@gatworks.com> References: <47865F1A.8040202@gatworks.com> Message-ID: Hi George, How are you doing? oh, what does it mean? (i'm totally newbie, *really*) Thanks :) Geraldo On 10/01/2008, U. George wrote: > Yes. > BUT rs232 is an electrical specification used by the serial port of many > many computers for many years. > > Geraldo Netto wrote: > > Hi Guys, > > > > how are you doing? > > > > Sorry for this newbie question, > > but i was not able to find out this information > > > > does rxtx supports rs232? > > if not, any suggestion? > > > > Kind Regards and Best wishes, > > > > Geraldo > > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From rspencer at FuelQuest.com Thu Jan 10 13:48:15 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 14:48:15 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Trent, Do you compile in Windows? If so how? Can you attach your makefile? Thanks. Rodney Spencer Integration Engineer Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com ======================================================================== ==================================== This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender by reply email and destroy all copies of the original message. ======================================================================== ==================================== -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Wednesday, January 09, 2008 9:38 PM To: Spencer, Rodney Cc: rxtx at qbang.org Subject: Re: [Rxtx] Compiling in Windows On Wed, 9 Jan 2008, Spencer, Rodney wrote: > I'm having a tough time getting RXTX to compile in Window (DOS or > CYGWIN) can anyone give some help on this? > > > > This is what I get using LCC: > > C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 > > C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin > > C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW > > C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc > > C:\code\rxtx-devel\src>set CLASSPATH=. > > C:\code\rxtx-devel\src>rem set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin > > C:\code\rxtx-devel\src>set > PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin > > C:\code\rxtx-devel\src>make -f ..\Makefile.lcc > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c > > cpp: init.c:6 Could not find include file > > 0 errors, 1 warning > > lcc -I\C:\tools\jdk1.6.0_03\include > -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c > The directories look about right (assuming jni.h is in the include dir). There appears to be an extra '\' character in the PATHS: -I'\'C:\.... -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jan 10 14:21:50 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 14:21:50 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make I've not used lcc in a long time, I see you are really close. I think you want to comment out the header files that are being included from lcc' sys/ directory and it should work or be a fix from working. I did not have time to look into your mingw32 native windows compile. I suspect it has something to do with make being confused about \ being a directory rather thant \\. \ is an escape char in GNU Make. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > Trent, > Do you compile in Windows? If so how? Can you attach your makefile? > > > Thanks. > Rodney Spencer > Integration Engineer > > Phone: 832.668.5570 | Blackberry: 713.505.5795 | www.fuelquest.com > ======================================================================== > ==================================== > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. > Any unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please notify the sender by reply > email and destroy all copies of the original message. > ======================================================================== > ==================================== > > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Wednesday, January 09, 2008 9:38 PM > To: Spencer, Rodney > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Compiling in Windows > > On Wed, 9 Jan 2008, Spencer, Rodney wrote: > >> I'm having a tough time getting RXTX to compile in Window (DOS or >> CYGWIN) can anyone give some help on this? >> >> >> >> This is what I get using LCC: >> >> C:\code\rxtx-devel\src>set JAVA_HOME=C:\tools\jdk1.6.0_03 >> >> C:\code\rxtx-devel\src>set CYGWIN_HOME=C:\cygwin >> >> C:\code\rxtx-devel\src>set MINGW_HOME=C:\tools\MinGW >> >> C:\code\rxtx-devel\src>set LCC_HOME=C:\tools\lcc >> >> C:\code\rxtx-devel\src>set CLASSPATH=. >> >> C:\code\rxtx-devel\src>rem set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin;%MINGW_HOME%\bin >> >> C:\code\rxtx-devel\src>set >> PATH=%JAVA_HOME%\bin;%CYGWIN_HOME%\bin;%LCC_HOME%\bin >> >> C:\code\rxtx-devel\src>make -f ..\Makefile.lcc >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. init.c >> >> cpp: init.c:6 Could not find include file >> >> 0 errors, 1 warning >> >> lcc -I\C:\tools\jdk1.6.0_03\include >> -I\C:\tools\jdk1.6.0_03\include\win32 -I. SerialImp.c >> > > The directories look about right (assuming jni.h is in the include dir). > > There appears to be an extra '\' character in the PATHS: > > -I'\'C:\.... > > -- > Trent Jarvi > tjarvi at qbang.org > From rspencer at FuelQuest.com Thu Jan 10 15:54:20 2008 From: rspencer at FuelQuest.com (Spencer, Rodney) Date: Thu, 10 Jan 2008 16:54:20 -0600 Subject: [Rxtx] Compiling in Windows References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> Message-ID: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> I have given up on trying compiling from native Windows. I am turning to cross-compiling in Linux. I think I have everything setup, however I'm getting the error (as seen below), it's probably a simple thing but as you can see I'm having trouble with a lot. [qatomcat at frogger build]$ export MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" [qatomcat at frogger build]$ export WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE jawt_md.h jni_md.h [qatomcat at frogger build]$ ../configure --target=i386-mingw32 checking build system type... i686-pc-linux-gnuoldld checking host system type... i686-pc-linux-gnuoldld checking target system type... i386-pc-mingw32 configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. -----Original Message----- I compile windows using a cross compiler from linux. That is just done with: ./configure --target=i386-mingw32 make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0019.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 6512 bytes Desc: config.log Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080110/f05ca5c4/attachment-0019.obj From tjarvi at qbang.org Thu Jan 10 16:36:54 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Jan 2008 16:36:54 -0700 (MST) Subject: [Rxtx] Compiling in Windows In-Reply-To: <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> References: <29EA34939634AE4D8C5CF241CC3D2B1702DA8E48@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA91E9@fqmx03.fuelquest.com> <29EA34939634AE4D8C5CF241CC3D2B1702DA9298@fqmx03.fuelquest.com> Message-ID: Your other builds are probably just as close. If you want to do the cross compiler, you need the mingw32 cross compiler installed. There are many examples showing how to do it. I see one here: http://www.wxwidgets.org/wiki/index.php/Install_The_Mingw_Cross-Compiler It documents most distros. Just put the bin directory the cross compiler is in at the front of your PATH. Sometimes the C++ portion is problematic but rxtx does not use that. If you have the compiler installed, it should work as long as it is ahead of the normal gcc on your path when you type configure. On Thu, 10 Jan 2008, Spencer, Rodney wrote: > I have given up on trying compiling from native Windows. I am turning to > cross-compiling in Linux. > > > > I think I have everything setup, however I'm getting the error (as seen > below), it's probably a simple thing but as you can see I'm having > trouble with a lot. > > > > [qatomcat at frogger build]$ export > MINGW_HOME="/home/export/qatomcat/rxtx-stuff/cross-tools/i386-mingw32" > > [qatomcat at frogger build]$ export > WIN32INCLUDE="/home/export/qatomcat/rxtx-stuff/win32java" > > [qatomcat at frogger build]$ export PATH="${MINGW_HOME}/bin:${PATH}" > > [qatomcat at frogger build]$ ls -1 $WIN32INCLUDE > > jawt_md.h > > jni_md.h > > > > [qatomcat at frogger build]$ ../configure --target=i386-mingw32 > > checking build system type... i686-pc-linux-gnuoldld > > checking host system type... i686-pc-linux-gnuoldld > > checking target system type... i386-pc-mingw32 > > configure: WARNING: Trying libtool. If the following fails install > libtool > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > > > -----Original Message----- > I compile windows using a cross compiler from linux. That is just done > > with: > > > > ./configure --target=i386-mingw32 > > make > > From michael.erskine at ketech.com Fri Jan 11 02:51:42 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Fri, 11 Jan 2008 09:51:42 +0000 Subject: [Rxtx] rs232 support? In-Reply-To: References: <47865F1A.8040202@gatworks.com> Message-ID: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Geraldo Netto wrote: - > Subject: Re: [Rxtx] rs232 support? > oh, what does it mean? > (i'm totally newbie, *really*) > Thanks :) > Geraldo OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - http://en.wikipedia.org/wiki/Serial_port http://en.wikipedia.org/wiki/Rs232 http://en.wikipedia.org/wiki/UART There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. Regards, Michael Erskine. From lyon at docjava.com Fri Jan 11 03:17:42 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 11 Jan 2008 05:17:42 -0500 Subject: [Rxtx] freeBsd In-Reply-To: References: Message-ID: Hi All, My goal is to get an automatic install going on FreeBSD. I think that my GUESS that Linux shared libs would work with FreeBSD was wrong. I have since downloaded the old javax.comm shared BSD libs; libParallel.so libSerial.so file * libParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped libSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped 13271 Jul 20 2004 libSerial.so Vs. librxtxParallel.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 55564 Mar 31 2007 librxtxSerial.so Aside from the obvious name change, the older libs are from jdk1.4 and a very different version of the Java source code. Also, one is compiled for FreeBSD, and another for SysV. And oh, the size has increased by a factor of 5 in the last 3 years. Hmmm. Do we need a fresh build on a FreeBSD system to get this working? Thanks! - Doug From geraldonetto at gmail.com Fri Jan 11 03:19:18 2008 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Jan 2008 08:19:18 -0200 Subject: [Rxtx] rs232 support? In-Reply-To: <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> References: <47865F1A.8040202@gatworks.com> <06BA3262D918014F9183B66425D5A8D42523FCDE90@no-sv-03.ketech.local> Message-ID: Hi Guys, Don't worry Michael :) actually, i'm developing a distributed scada system and i want to use rxtx as a plc driver (lots of plc use serial ports, new ones use ethernet...) Kind Regards and Best wishes, Geraldo On 11/01/2008, Michael Erskine wrote: > > Geraldo Netto wrote: - > > Subject: Re: [Rxtx] rs232 support? > > oh, what does it mean? > > (i'm totally newbie, *really*) > > Thanks :) > > Geraldo > > OK, if you want to know more about serial communications, and its nomenclature, take a look at some basic information that is easily found on the net, e.g. the Wikipedia pages: - > > http://en.wikipedia.org/wiki/Serial_port > http://en.wikipedia.org/wiki/Rs232 > http://en.wikipedia.org/wiki/UART > > There's probably some good introductions to serial communications out there: if something like an "internet search engine" existed you might venture using it :) > > Sorry for the sarcasm fella -- if I had more time I'd pick out a good one for you. What sort of thing do you need to do with rxtx? I imagine you want to communicate with a particular serial device using your serial ports. Perhaps we can help with a nice example. > > Regards, > Michael Erskine. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- site: http://extremedev.sf.net msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 From ajmas at sympatico.ca Sat Jan 12 14:09:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 16:09:36 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: Message-ID: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> On 8-Jan-08, at 08:12 , Dr. Douglas Lyon wrote: > >> From the webstart programmer point of view, the arch is used to >> direct the > location search of a native resource; Thus: > > > > > > > download="eager"/> > > This shouldn't be necessary at all, since if the library is built as a universal binary then it will include both architectures, and it is the system which will do the magic for you. It should be not Note if you run the 'file' command against the library and only see one architecture then I recommend you get the latest source from CVS and build with that, since it is now capable of creating a universal binary. The result is as follows: myhost$ file librxtxSerial.jnilib librxtxSerial.jnilib: Mach-O universal binary with 3 architectures librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle x86_64 Alternatively, the library included here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip is universal for MacOS X. Andre From tjarvi at qbang.org Sat Jan 12 14:26:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 12 Jan 2008 14:26:12 -0700 (MST) Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: > myhost$ file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O universal binary with 3 architectures > librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 > librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc > librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle > x86_64 Dang that is slick. I'm green with envey. What would be involved to make that work on other OS's? In the (dated) ToyBox, for instance, we have ~20 linux binaries. I would love to have a 'jnilib' for Linux so the embeded folks could just grab, perhaps Dougs package, and go. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Jan 12 18:21:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 12 Jan 2008 20:21:55 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> Message-ID: <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> On 12-Jan-08, at 16:26 , Trent Jarvi wrote: >> myhost$ file librxtxSerial.jnilib >> librxtxSerial.jnilib: Mach-O universal binary with 3 architectures >> librxtxSerial.jnilib (for architecture i386): Mach-O bundle i386 >> librxtxSerial.jnilib (for architecture ppc): Mach-O bundle ppc >> librxtxSerial.jnilib (for architecture x86_64): Mach-O 64-bit bundle >> x86_64 > > Dang that is slick. I'm green with envey. What would be involved > to make that work on other OS's? > > In the (dated) ToyBox, for instance, we have ~20 linux binaries. I > would love to have a 'jnilib' for Linux so the embeded folks could > just grab, perhaps Dougs package, and go. > This a feature of the OS and applies to any executable binary (dylibs, jnilib, app, etc). To get something like this on Linux, would depend on getting the OS to support it. I am not aware of any initiative to replicate this approach on Linux. BTW I could have gone one step further on the Mac, and added 64-bit PPC support, but decided those three would be enough. Andre From ajmas at sympatico.ca Sun Jan 13 08:47:12 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 10:47:12 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: On 13-Jan-08, at 10:23 , Dr. Douglas Lyon wrote: > Hi Andre, > Thank you for looking into this. > Let me see if I can address your e-mail, below: >> Hi, >> >> I just download the source and notice I get the same error about >> the Headers directory not being found. Looks like the right path >> should be: >> >> /System/Library/Frameworks/JavaVM.framework/Home/../Headers >> I have just tried the configure script on my old PowerPC machine and don't get the above error. Looks like line 462 in configure.in needs to be changed, since: $JAVA_HOME/include works on MacOS X, and the current value is hit and miss depending on the JAVA_HOME value. On my portable it is: /System/Library/Frameworks/JavaVM.framework/Home/ on my old PPC machine: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home I'll see about getting a patch out for that, but that will have to wait a little, since I don't have time right now. >> But this does not seem to prevent configure from completing. It >> should be noted that you can correct this path as per in the >> instructions in the warnings. >> >> As to the issue which is causing the makefile not be generated, I >> am guessing it has something to do with the line mentioning sed, >> since I don't get that. To help me diagnose the issue, could you >> tell me the results of the following: >> >> which sed > > which sed > /usr/bin/sed That's the same as mine. >> echo $CFLAGS >> echo $LDFLAGS > > echo $CFLAGS > -ansi > macbook.docjava.com{lyon}160: echo $LDFLAGS > tcsh: LDFLAGS: Undefined variable. Could you try clearing the CFLAGS value and see if it changes anything? I doubt that is the issue though. Something worth trying: autoconf ./configure Andre From ajmas at sympatico.ca Sun Jan 13 12:59:56 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 14:59:56 -0500 Subject: [Rxtx] configure.in issue Message-ID: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Hi, There appears to be an issue in configure.in at line 769/770. I line break was inserted between the two, causing build problems on the Mac. I suspect that is might have been caused by formatting by the mail program when I submitted the patch. Can someone with the necessary cvs privileges fix this? - Thanks Andre From tjarvi at qbang.org Sun Jan 13 15:43:55 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 15:43:55 -0700 (MST) Subject: [Rxtx] configure.in issue In-Reply-To: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> References: <11483ED9-3227-4572-94C0-5C63A333A05D@sympatico.ca> Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > There appears to be an issue in configure.in at line 769/770. I line > break was inserted > between the two, causing build problems on the Mac. I suspect that is > might have been > caused by formatting by the mail program when I submitted the patch. > > Can someone with the necessary cvs privileges fix this? - Thanks > done. I also redid some logic so configure will not break in future java releases. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sun Jan 13 16:35:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sun, 13 Jan 2008 18:35:53 -0500 Subject: [Rxtx] Wiki down? Message-ID: Hi, Looks like the wiki is down. Was this intentional? Andre From tjarvi at qbang.org Sun Jan 13 16:46:56 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 13 Jan 2008 16:46:56 -0700 (MST) Subject: [Rxtx] Wiki down? In-Reply-To: References: Message-ID: On Sun, 13 Jan 2008, Andre-John Mas wrote: > Hi, > > Looks like the wiki is down. Was this intentional? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks Andre-John. What happened was a bit unusual. qbang.org is back in colorado in my parents basement. It is a fairly big dual opteron system that does everything for my family. http://www.qbang.org/qbang/ The system is a bit unusual. It is the desktop for my parents dumb terminals. That way I can admin it from boston. My mother was reading email from someone proposing a new design for their kitchen. pdf files. She was trying to print them all and ended up filling up qbangs 57G (yes G) tmp directory with open deleted files. This created all sorts of issues this evening that I'm still cleaning up. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jan 14 18:52:35 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 20:52:35 -0500 Subject: [Rxtx] On the subject of automatic multi-platform support for rxtx In-Reply-To: References: <42436EE4-FA1E-485B-999C-543919567DEA@sympatico.ca> <6831B53F-D8EA-41DA-824F-4EAD5502975E@sympatico.ca> Message-ID: <476DF0E7-3487-4590-96AF-FA278DEE417C@sympatico.ca> On 14-Jan-08, at 14:35 , Dr. Douglas Lyon wrote: >> Hi Andre, > > > Did you set an environment variable for your JAVAINCLUDEDIR? No, it shouldn't be necessary. I think that > I think it is supposed to be: > /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/ > > ON THE OLD Version of the RXTX, here is what I used to do: > > I edit the make file and write: > #Here is what it was: > #JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/ > Home/../../../Head > ers > #Here is what I did: > JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/ > A/Headers/ > > The old rxtx make runs good now. > > But: > file librxtxSerial.jnilib > librxtxSerial.jnilib: Mach-O bundle i386 >> A few things have been fixed in the configure script in CVS, since the issue occurred. Could you do an update of your CVS checkout and try again. Note that I haven't addressed the JAVAINCLUDEDIR issue, I will see with Trent what can be done. Andre From ajmas at sympatico.ca Mon Jan 14 19:12:36 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 14 Jan 2008 21:12:36 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X Message-ID: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Hi, On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes fine, yet on my Intel, MacOS X 10.5.1 based I get the following warning: ./configure: line 21267: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory ./configure: line 21268: cd: /System/Library/Frameworks/ JavaVM.framework/Home//../../../Headers: No such file or directory 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: If there are more than one option available the first was selected. I notice that JAVA_HOME on the PPC machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home on my Intel machine: /System/Library/Frameworks/JavaVM.framework/Home/ A bit of analysis indicates that MacOS X is being special cased in the configure.in file: [ case $OS_NAME in Mac\ OS\ X) JAVAINCLUDEDIR=$JPATH/../../../Headers ;; *) JAVAINCLUDEDIR=$JPATH/include ;; esac ] I am not sure that the special case is really necessary, since if JAVA_HOME is not set, the general case works. On the other hand if JAVA_HOME is set then it all depends on the value of the variable whether JAVAINCLUDEDIR ends up being valid. I have attached a patch to this e-mail which I would like anyone with a Mac to test out. To use it make sure that your CVS is updated (the patch is against revision 1.35.2.78), and then in the rxtx-devel directory, ensuring the patch is saved there: patch < configure.in.patch autoconfg ./configure make Let me know if you have any issues. This works for me on 10.4.11 and 10.5, but I would like to make sure before having this patch checked-in. Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.in.patch Type: application/octet-stream Size: 683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080114/84059c3f/attachment-0015.obj -------------- next part -------------- From tjarvi at qbang.org Mon Jan 14 19:46:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 14 Jan 2008 19:46:53 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On Mon, 14 Jan 2008, Andre-John Mas wrote: > Hi, > > On my PPC, MacOS X 10.4.11 based, system when I compile rxtx everything goes > fine, > yet on my Intel, MacOS X 10.5.1 based I get the following warning: > > ./configure: line 21267: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > ./configure: line 21268: cd: > /System/Library/Frameworks/JavaVM.framework/Home//../../../Headers: No such > file or directory > > 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: > > If there are more than one option available the first was selected. > > I notice that JAVA_HOME on the PPC machine is: > > /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home > > on my Intel machine: > > /System/Library/Frameworks/JavaVM.framework/Home/ > > A bit of analysis indicates that MacOS X is being special cased in the > configure.in file: > > [ case $OS_NAME in > Mac\ OS\ X) > JAVAINCLUDEDIR=$JPATH/../../../Headers > ;; > *) > JAVAINCLUDEDIR=$JPATH/include > ;; > esac ] > > I am not sure that the special case is really necessary, since if JAVA_HOME > is not set, the general case works. On the other hand if JAVA_HOME is set > then it all depends on the value of the variable whether JAVAINCLUDEDIR ends > up being valid. I have attached a patch to this e-mail which I would like > anyone with a Mac to test out. To use it make sure that your CVS is updated > (the patch is against revision 1.35.2.78), and then in the rxtx-devel > directory, ensuring the patch is saved there: > > patch < configure.in.patch > autoconfg > ./configure > make > > > Let me know if you have any issues. This works for me on 10.4.11 and 10.5, > but I would like to make sure before having this patch checked-in. > The Mac OS X case was probably a hack at the time. One thing that would be good to check as you have the machine: The configure script should work without JAVA_HOME being set and with java/javac on your path. There is code in configure that overides the path if JAVA_HOME is set. It determines JPATH. If that's default to have JAVA_HOME set on Mac OS X, then don't worry. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Wed Jan 16 05:49:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 16 Jan 2008 07:49:29 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: Hi All, I was wondering if anyone has tried using the RXTX package to communicate with USB devices on a mac? I was thinking about the USB Lego IRTower and or the USB-based Dymo labelwriter. Everything is USB now a days. Thanks! - Doug From netbeans at gatworks.com Wed Jan 16 09:02:11 2008 From: netbeans at gatworks.com (U. George) Date: Wed, 16 Jan 2008 11:02:11 -0500 Subject: [Rxtx] dymo labelwriter In-Reply-To: References: Message-ID: <478E2A83.6030000@gatworks.com> I suppose that all depends on how the device and the necessary device driver presents itself to the user application. This is not just a MAC issue. Dr. Douglas Lyon wrote: > Hi All, > I was wondering if anyone has tried using > the RXTX package to communicate with USB devices > on a mac? > > I was thinking about the USB Lego IRTower and or the > USB-based Dymo labelwriter. Everything is USB now a days. > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Wed Jan 16 13:10:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 16 Jan 2008 15:10:41 -0500 Subject: [Rxtx] dymo labelwriter Message-ID: <6buhm2$55olri@toip7.srvr.bell.ca> U. George wrote > > I suppose that all depends on how the device and the necessary device > driver presents itself to the user application. > This is not just a MAC issue. > Yup, from what I can tell the device would have to present itself to the computer as a serial device, otherwise you are going to have to use USB communication methods. This may be a useful reference: http://www.ibm.com/developerworks/java/library/j-usb.html I don't have any experience with jUSB, so I can't really help much beyond that. Andre From marcopar at gmail.com Thu Jan 17 07:35:39 2008 From: marcopar at gmail.com (marcopar at gmail.com) Date: Thu, 17 Jan 2008 15:35:39 +0100 Subject: [Rxtx] legacy software using rxtx and javacomm Message-ID: <478F67BB.4060701@gmail.com> Hi all,i have a problem with a piece of software i made few years ago. It uses rxtx with sun's comm api (damn, it would have been better to choose the "standalone" version of rxtx like i'm doing recently) and it runs under Linux. I need to make a minor update but the JVM keeps crashing. I'm developing and testing on Debian Etch. I'm using rxtx-2.0-7pre1. JVM is 1.5.0_08-b03 I put up a test case to simplify my debug process: public static void main(String args[]) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList. nextElement(); if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { continue; } if(portId.isCurrentlyOwned()) { continue; } try { CommPort cp = portId.open("SerialPortHandler test", 2000); cp.close(); } catch(PortInUseException e) { System.err.println("Occupied port: " + portId.getName()); continue; } System.err.println("Found port: " + portId.getName()); } } This piece of code crashes the JVM always on at least 2 machines i've tried. Full details about the crash can be found here: http://www.flatworld.eu/crash.log In order to use the library i performed these steps: - put the jar in the program classpath - copied the *.so files in the running directory of the software. I run the sw passing -Djava.library.path=. to the JVM in order to let it find the .so files - created the file /lib/javax.comm.properties with content: Driver=gnu.io.RXTXCommDriver Thanks for any advice ciao From netbeans at gatworks.com Thu Jan 17 12:40:33 2008 From: netbeans at gatworks.com (U. George) Date: Thu, 17 Jan 2008 14:40:33 -0500 Subject: [Rxtx] legacy software using rxtx and javacomm In-Reply-To: <478F67BB.4060701@gmail.com> References: <478F67BB.4060701@gmail.com> Message-ID: <478FAF31.1070907@gatworks.com> from the stack trace, it appears that the linker/loader, in particular dlopen() is barfing about something in the shared rxtx library. I would recompile the shared rxtx lib on your current system. This way rxtx and the linker/loader are in sync, and happy. marcopar at gmail.com wrote: > Hi all,i have a problem with a piece of software i made few years ago. > It uses rxtx with sun's comm api (damn, it would have been better to > choose the "standalone" version of rxtx like i'm doing recently) and it > runs under Linux. > > I need to make a minor update but the JVM keeps crashing. > > I'm developing and testing on Debian Etch. > I'm using rxtx-2.0-7pre1. > JVM is 1.5.0_08-b03 > > I put up a test case to simplify my debug process: > > public static void main(String args[]) { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList. > nextElement(); > > if(portId.getPortType() != CommPortIdentifier.PORT_SERIAL) { > continue; > } > > if(portId.isCurrentlyOwned()) { > continue; > } > > try { > CommPort cp = portId.open("SerialPortHandler test", 2000); > cp.close(); > } catch(PortInUseException e) { > System.err.println("Occupied port: " + portId.getName()); > continue; > } > System.err.println("Found port: " + portId.getName()); > } > } > > This piece of code crashes the JVM always on at least 2 machines i've tried. > Full details about the crash can be found here: > http://www.flatworld.eu/crash.log > > In order to use the library i performed these steps: > - put the jar in the program classpath > - copied the *.so files in the running directory of the software. I run > the sw passing -Djava.library.path=. to the JVM in order to let it find > the .so files > - created the file /lib/javax.comm.properties with content: > Driver=gnu.io.RXTXCommDriver > > Thanks for any advice > ciao > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ajmas at sympatico.ca Thu Jan 17 23:17:11 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 01:17:11 -0500 Subject: [Rxtx] configure.in changes, for MacOS X Message-ID: <01AC06F4-9397-410A-B3D5-4B2D0FC56A03@sympatico.ca> Hi, I just made a modification to the configure.in and configure, with regards to universal binaries on Macs: - I removed support for 64-bit Intel support, since this appears to require the 10.5 SDK and I believe it is better to stick with with 10.4 SDK for the moment. So the universal binary is currently 32-bit Intel and 32- bit PPC. - Additionally an issue was corrected whereby the linker would fail because it was not pointing the 10.4 SDK, while the compiler was. This was mainly an issue for builds on PPC machines from what I can tell. Note on MacOS X you can check to see what architectures a binary has by using the 'file' command in the terminal. Andre From zuran at pandora.be Fri Jan 18 01:17:34 2008 From: zuran at pandora.be (Danny Dom) Date: Fri, 18 Jan 2008 09:17:34 +0100 Subject: [Rxtx] pattern to use Message-ID: <002001c859aa$943e91a0$a601a8c0@dannycomp> Hi, Any of you know what is the best pattern to use in Java for the following situation I would like to have a class that has the following method public String SendToUart(String tosend){ } Where I want to send something to the Uart, Wait for receiving data, capture the data till the message is completed ( begin -- end char) then send the String back. has to be singleton, several other classes makes use of it regards Zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/0d715d82/attachment-0012.html From darioros at gmail.com Fri Jan 18 03:29:40 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 11:29:40 +0100 Subject: [Rxtx] rxtx osx Message-ID: Hello. I'm trying using this lib on MacOsx, but I'm facing some troubles. I just want to know if these drivers are still usable or if there are alternatives now... I've been trying to install rxtx on my Osx, but It has huge problems... well it just doesn't work. It pops out: java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while loading gnu.io.RXTXCommDriver just when I try to compile a simple class that lists the ports in the system. I used a binary package for Tiger and I think everything is fine... It doesn't complain it can't find gnu.io.*... It just pops out those messages when it starts up. I really can't get the problem. Do you know how I can solve this or where I can find some assistance? Thanks Dario -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f1c4524c/attachment-0012.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:50:59 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:50:59 +0100 Subject: [Rxtx] pattern to use In-Reply-To: <002001c859aa$943e91a0$a601a8c0@dannycomp> References: <002001c859aa$943e91a0$a601a8c0@dannycomp> Message-ID: <443F02FD-B8D5-49FE-B027-3BA2EC1CBEEB@gmail.com> Hi, I am not sure that your method as to be singleton (and consequently here a static one). You may have several comm ports for which you want such purpose. Maybe you can define a class (let us name it 'A') that includes a constructor which takes a SerialPort instance. Then, you can pass such A object to classes that need to use a particular port. this can be done via constructor arguments, or you can either define in your A class a stic method that allows to retrieve a particular A object (singleton capability). If several others classes can use the SendToUart method, theis method has to be declared synchronized in order to avoid concurrency problems. To summarize You can write it as following : pulic class A { private static Map ports = new Map (); public static A getByPortName(String portName) {return this.get(portName);} private SerialPort portToUse; public A (SerialPort toUse) throws AreadyCreatedException { if (A.ports.containsKey(toUse.getName()) throw new AlreadyCreatedException(); this.portToUse = toUse; A.ports.put(toUse.getName(), this); } public synchronized String sendTOUart(String toSend) { ...} } Hope this helps, Baz Le 18 janv. 08 ? 09:17, Danny Dom a ?crit : > Hi, > > Any of you know what is the best pattern to use in Java for the > following situation > > I would like to have a class that has the following method > public String SendToUart(String tosend){ > } > > Where I want to send something to the Uart, Wait for receiving data, > capture the data till the message is completed ( begin -- end char) > then send the String back. > > has to be singleton, several other classes makes use of it > > regards Zuran > > > _______________________________________________ > 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/20080118/cb0a4dd8/attachment-0012.html From sebastien.jean.rxtx at gmail.com Fri Jan 18 03:52:36 2008 From: sebastien.jean.rxtx at gmail.com (Sebastien Jean) Date: Fri, 18 Jan 2008 11:52:36 +0100 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <37377914-F11C-4FD6-B196-3BBDAF4F6AD2@gmail.com> The rxtx lib use the gnu.io package declaration. Perhaps your application still consider using javax.comm. Baz Le 18 janv. 08 ? 11:29, Dario Rossi a ?crit : > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. > > Do you know how I can solve this or where I can find some assistance? > > Thanks Dario _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Jan 18 05:01:29 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 18 Jan 2008 07:01:29 -0500 Subject: [Rxtx] jusb In-Reply-To: References: Message-ID: Hi All, Has anyone tried jusb on a mac? Thanks! - Doug From ajmas at sympatico.ca Fri Jan 18 07:22:21 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 09:22:21 -0500 Subject: [Rxtx] rxtx osx In-Reply-To: References: Message-ID: <20535E63-7898-4ED9-AFE2-4017DD1330DE@sympatico.ca> On 18-Jan-08, at 05:29 , Dario Rossi wrote: > Hello. I'm trying using this lib on MacOsx, but I'm facing some > troubles. I just want to know if these drivers are still usable or > if there are alternatives now... I've been trying to install rxtx on > my Osx, but It has huge problems... well it just doesn't work. It > pops out: > > java.lang.NoClassDefFoundError: javax/comm/CommDriver thrown while > loading gnu.io.RXTXCommDriver > > just when I try to compile a simple class that lists the ports in > the system. I used a binary package for Tiger and I think everything > is fine... > > It doesn't complain it can't find gnu.io.*... It just pops out those > messages when it starts up. I really can't get the problem. It sound like your are depending on the wrong version of RxTx. You should be importing gnu.io.*. The latest RxTx version while being specification compatible with javax.comm does not use the same package. Andre From darioros at gmail.com Fri Jan 18 07:55:54 2008 From: darioros at gmail.com (Dario Rossi) Date: Fri, 18 Jan 2008 15:55:54 +0100 Subject: [Rxtx] How to clean up everything? Message-ID: Hi there... still me... I think I messed up everything with my Osx install. Is there a way of cleaning it all??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/f836a9eb/attachment-0011.html From beat.arnet at gmail.com Fri Jan 18 10:59:12 2008 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 18 Jan 2008 12:59:12 -0500 Subject: [Rxtx] Problems with getting CVS source code Message-ID: So sorry to bother you all with this, but I am having problems checking out the source code with cvsnt, following the instruction given in the RXTX wiki. Is the following still correct: username: anonymous at cvs.milestonesolutions.com password: mousy Thanks, Beat C:\Program Files\CVSNT>set CVSROOT=: pserver:anonymous at cvs.milestonesolutions.com :/usr/local/cvsroot C:\Program Files\CVSNT>cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 :/usr/local/cvsr oot CVS Password: connect to cvs.milestonesolutions.com:2401 failed: No connection could be made b ecause the target machine actively refused it. C:\Program Files\CVSNT> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080118/93171dd5/attachment-0011.html From tjarvi at qbang.org Fri Jan 18 11:27:03 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 18 Jan 2008 11:27:03 -0700 (MST) Subject: [Rxtx] Problems with getting CVS source code In-Reply-To: References: Message-ID: On Fri, 18 Jan 2008, Beat Arnet wrote: > So sorry to bother you all with this, but I am having problems checking out > the source code with cvsnt, following the instruction given in the RXTX > wiki. Is the following still correct: > > username: anonymous at cvs.milestonesolutions.com > password: mousy > > Thanks, > Beat > > > C:\Program Files\CVSNT>set CVSROOT=: > pserver:anonymous at cvs.milestonesolutions.com > :/usr/local/cvsroot > > C:\Program Files\CVSNT>cvs login > Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401 > :/usr/local/cvsr > oot > CVS Password: > connect to cvs.milestonesolutions.com:2401 failed: No connection could be > made b > ecause the target machine actively refused it. > C:\Program Files\CVSNT> > It appears to be working: % cvs login Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401/usr/local/cvsroot CVS password: % -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri Jan 18 20:53:27 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 18 Jan 2008 22:53:27 -0500 Subject: [Rxtx] How to clean up everything? In-Reply-To: References: Message-ID: How did you install it? On 18-Jan-08, at 09:55 , Dario Rossi wrote: > Hi there... still me... > > I think I messed up everything with my Osx install. Is there a way > of cleaning it all??? > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Fri Jan 18 22:48:55 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:48:55 -0500 Subject: [Rxtx] Webstart issues on MacOS X In-Reply-To: <47918CFE.20509@gmail.com> References: <8AD6E05E-CE01-4FE3-B7C2-FAC309A45658@amug.org> <47918CFE.20509@gmail.com> Message-ID: <529698A6-D453-4889-AE77-D80E788C32AC@sympatico.ca> On 19-Jan-08, at 00:39 , Moises Lejter wrote: > Hi! > > Did you try requesting all-permissions on the main JNLP file? It > looks like you only request it on the extension... I just have and it looks like that was the issue :) Thanks everyone for you help. Andre From ajmas at sympatico.ca Fri Jan 18 22:51:29 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 00:51:29 -0500 Subject: [Rxtx] GPS Viewer, using RXTX Message-ID: <138BB346-5EEC-4C8C-A459-76396C7148ED@sympatico.ca> Hi, I have just thrown together a GPSViewer, with the help of RXTX, which you can try out if you are interested: http://ajmas.dyndns.org/webstart/applications/gpsviewer.jnlp I have only done basic testing. This requires an NMEA compatible GPS to be connected. Would be interested in any feedback. Andre From ajmas at sympatico.ca Sat Jan 19 08:46:02 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 19 Jan 2008 10:46:02 -0500 Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: On 14-Jan-08, at 21:46 , Trent Jarvi wrote: >> > The Mac OS X case was probably a hack at the time. One thing that > would be good to check as you have the machine: The configure > script should work without JAVA_HOME being set and with java/javac > on your path. > > There is code in configure that overides the path if JAVA_HOME is > set. It determines JPATH. > > If that's default to have JAVA_HOME set on Mac OS X, then don't worry. Hi, I tested with both JAVA_HOME set and unset. Configure will run perfectly if the variable is not set. On the other hand it is hit and miss whether it works when it is set. Removing the special case for the Mac results in configure that works in both cases. It would appear that JPATH is calculated correctly when it is not set and when JAVA_HOME is set it will take that value. Currently I have tested having: JAVAINCLUDEDIR=$JPATH/include on both MacOS X 10.4 and 10.5 and this works fine. The only scenario I can see this failing is if the JAVA_HOME is JDK 1.3. The truth it only JDK 1.4+ on MacOS X that conforms properly to the directory structure and I am not even sure that we should be supporting JDK 1.3 any more on the Mac. From what I can tell JDK 1.4 came with MacOS X 10.3, so I doubt we should even consider support for MacOS X 10.2, except as a special case, which could be defined by a configure option if need be. Andre From tjarvi at qbang.org Sat Jan 19 11:32:43 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 19 Jan 2008 11:32:43 -0700 (MST) Subject: [Rxtx] Configure.in & JAVAINCLUDEDIR on MacOS X In-Reply-To: References: <72D749AA-BA9F-4870-90DE-D34FEE5FD447@sympatico.ca> Message-ID: